title: 400 vs 422 for Client Error Request
body: <p>I've read a lot of posts and articles regarding proper http status code to return for client request error.
  Others suggest to use 400 as it has been redefined in <a href="https://www.rfc-editor.org/rfc/rfc7231#section-6.5.1" rel="noreferrer">RFC 7231</a> though I'm not sure if the example given covers all the client error in my mind because the examples are syntactic.</p>
  <blockquote>
  <p>The 400 (Bad Request) status code indicates that the server cannot or
  will not process the request due to something that is perceived to be
  a client error (e.g., malformed request syntax, invalid request<br />
  message framing, or deceptive request routing).</p>
  </blockquote>
  <p>I did find this statement in the Appendix B of the rfc 7231:</p>
  <blockquote>
  <p>The 400 (Bad Request) status code has been relaxed so that it isn't<br />
  limited to syntax errors.  (Section 6.5.1)</p>
  </blockquote>
  <p>Does this mean that I can consider any type of client error a bad request? Would it be better to use 400 for client requests and just specify a more specific error in the message?</p>
  <br>
  On the other hand, others say that it's better to use 422 (Unprocessable Entity). While this is more focused on semantics, it's only listed in [RFC 4918][2] which is a webDAV extension for http/1.1
  <blockquote>
  <p>The 422 (Unprocessable Entity) status code means the server<br />
  understands the content type of the request entity (hence a<br />
  415(Unsupported Media Type) status code is inappropriate), and the<br />
  syntax of the request entity is correct (thus a 400 (Bad Request)<br />
  status code is inappropriate) but was unable to process the contained
  instructions.  For example, this error condition may occur if an XML<br />
  request body contains well-formed (i.e., syntactically correct), but<br />
  semantically erroneous, XML instructions.</p>
  </blockquote>
  <p>Can I use this webDAV extension codes to handle my http requests? In the case of 422, can I use it even though it's not in the core http codes. <br></p>
  <p>Should I use 400 or 422 for my client error?</p>
  <p>Here are the possible client error I have in mind:</p>
  <pre><code>1.) Invalid parameter. The client provided parameters but are found invalid. Example: I said that the userId is 1, but when I checked there's no userId of 1. Another example of invalid parameter is wrong data type.
  2.) Missing required parameters
  3.) Let's say I need to hash a value based on given params and it failed 
  4.) Blocked content is being used. Like, i want to apply for membership and i passed the userId of 1. However, userId of one is blocked / deactivated
  5.) When I try to delete an entry but the entry is still being used in another table. 
  6.) Let's say i require a signature in my payload and the signature does not match when recalculated in the backend
  7.) Let's say I have a value that counts a specific attribute like &quot;shares&quot; and it has reached the maximum value like 10.
  etc...
  </code></pre>
  <br>
  Any informative response will be highly appreciated. Thanks a lot, guys!
  <p>Update: I checked google api errors and they are not using 422. On the other hand, Twitter uses 422. I'm more confused than ever &gt;.&lt; Though there's a part of me that thinks 400 is the better choice as it is included in the RFC doc and 422 is not. I could be wrong though.</p>