Right HTTP status code to wrong input

Question

What is optimal HTTP response Code when not reporting 200  everything OK  but error in input     Like  you submit some data to server  and it will response that your data is wrong    using 500 looks more like Server Issue  using 200 with warning error response text is bad  allowing caching and everything is not OK   using 204 and returning nothing  is maybe good  but well supported    using 404 is wrong if requested path  script  is available and in proper place

User · Accepted Answer

We had the same problem when making our API as well. We were looking for an HTTP status code equivalent to an InvalidArgumentException. After reading the source article below, we ended up using 422 Unprocessable Entity which states:

The 422 (Unprocessable Entity) status code means the server understands the content type of the request entity (hence a 415 (Unsupported Media Type) status code is inappropriate), and the syntax of the request entity is correct (thus a 400 (Bad Request) status code is inappropriate) but was unable to process the contained instructions. For example, this error condition may occur if an XML request body contains well-formed (i.e., syntactically correct), but semantically erroneous, XML instructions.

source: https://www.bennadel.com/blog/2434-http-status-codes-for-invalid-data-400-vs-422.htm

User · Answer

Codes starting with 4  4xx  are meant for client errors  Maybe 400  Bad Request  could be suitable to this case  Definition in http   www w3 org Protocols rfc2616 rfc2616-sec10 html says    The request could not be understood by the server due to malformed syntax  The client SHOULD NOT repeat the request without modifications

User · Answer

According to the below scenario     Let s say that someone makes a request to your server with data that is in the correct format  but is simply not  good  data  So for example  imagine that someone posted a String value to an API endpoint that expected a String value  but  the value of the string contained data that was blacklisted  ex  preventing people from using  password  as their password   then the status code could be either 400 or 422    Until now  I would have returned a  400 Bad Request   which  according to the w3 org  means      The request could not be understood by the server due to malformed   syntax  The client SHOULD NOT repeat the request without   modifications    This description doesn t quite fit the circumstance  but  if you go by the list of core HTTP status codes defined in the HTTP 1 1 protocol  it s probably your best bet   Recently  however  Someone from my Dev team pointed out  to me  that popular APIs are starting to use HTTP extensions to get more granular with their error reporting  Specifically  many APIs  like Twitter and Recurly  are using the status code  422 Unprocessable Entity  as defined in the HTTP extension for WebDAV  HTTP status code 422 states      The 422  Unprocessable Entity  status code means the server   understands the content type of the request entity  hence a 415    Unsupported Media Type  status code is inappropriate   and the syntax   of the request entity is correct  thus a 400  Bad Request  status code   is inappropriate  but was unable to process the contained   instructions  For example  this error condition may occur if an XML   request body contains well-formed  i e   syntactically correct   but   semantically erroneous  XML instructions    Going back to our password example from above  this 422 status code feels much more appropriate  The server understands what you re trying to do  and it understands the data that you re submitting  it simply won t let that data be processed

User · Answer

409 Conflict could be an acceptable solution   According to  https   www w3 org Protocols rfc2616 rfc2616-sec10 html     The request could not be completed due to a conflict with the current state of the resource  This code is only allowed in situations where it is expected that the user might be able to resolve the conflict and resubmit the request  The response body SHOULD include enough information for the user to recognize the source of the conflict  Ideally  the response entity would include enough information for the user or user agent to fix the problem  however  that might not be possible and is not required    The doc continues with an example      Conflicts are most likely to occur in response to a PUT request  For example  if versioning were being used and the entity being PUT included changes to a resource which conflict with those made by an earlier  third-party  request  the server might use the 409 response to indicate that it can t complete the request  In this case  the response entity would likely contain a list of the differences between the two versions in a format defined by the response Content-Type      In my case  I would like to PUT a string  that must be unique  to a database via an API  Before adding it to the database  I am checking that it is not already in the database   If it is  I will return  Error  The string is already in the database   409   I believe this is what the OP wanted  an error code suitable for when the data does not pass the server s criteria

User · Answer

In addition to the RFC Spec  you can also see this in action  Check out the twitter responses  https   developer twitter com en docs ads general guides response-codes

User · Answer

404 - Not Found - can be used for The URI requested is invalid or the resource requested such as a user  does not exists

[api] Right HTTP status code to wrong input

Examples related to api

Examples related to http

Examples related to validation

Examples related to http-status-code-415