What HTTP status code should be used for 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

Blizzard

I would think 404 can and should also be used if the requested entity from the client could not be found by the requested path/script that is present and in proper place – Marchellemarcher

Answer 1

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

Sandbag

Answer 2

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. "

Exaggerate

400 Bad Request isn't bad but should generally be reserved for malformed syntax. OP seems to be more concerned about a case with well-formed syntax but invalid values. Plus 400 is a fairly common "oh shit something wasn't right" response code which you might want to differentiate from a particular case of erroneous input. – Sandbag

Note that the wording was updated in RFC 7231, and the "The request could not be understood by the server due to malformed syntax" was updated to "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 message framing, or deceptive request routing)". – Achelous

@Achelous While that RFC expanded the category somewhat, all of the examples given are still invalid in the sense that the server isn't even sure what the client wanted. They are fundamental problems with the request and detecting/handling them does not require knowledge of the server's business logic. It still seems like IETF is strongly implying this is a different category from the client issuing a request that is potentially valid (and understood by the server) but disallowed by business rules. Meanwhile the description of 422, while less common, exactly matches the given situation. – Whorled

Answer 3

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.

Benign

This is what I used to use. But after rereading the documentation, I'm not sure that's correct. The client might be trying to update an entity from X to Y. But the entity is no longer in the X state, it's no in the Z state. So the conflict is that the state on the server is different than the state on the client. – Malti

Answer 4

Paradoxically, 202 Accepted could be helpful in this situation, especially for asynchronous processing.

The HyperText Transfer Protocol (HTTP) 202 Accepted response status code indicates that the request has been accepted for processing, but the processing has not been completed; in fact, processing may not have started yet. The request might or might not eventually be acted upon, as it might be disallowed when processing actually takes place.

Smidgen