What's an appropriate HTTP status code to return by a REST API service for a validation failure?

Question

I'm currently returning 401 Unauthorized whenever I encounter a validation failure in my Django/Piston based REST API application. Having had a look at the HTTP Status Code Registry I'm not convinced that this is an appropriate code for a validation failure, what do y'all recommend?

• 400 Bad Request
• 401 Unauthorized
• 403 Forbidden
• 405 Method Not Allowed
• 406 Not Acceptable
• 412 Precondition Failed
• 417 Expectation Failed
• 422 Unprocessable Entity
• 424 Failed Dependency

Update: "Validation failure" above means an application level data validation failure, i.e., incorrectly specified datetime, bogus email address etc.

Answer 1

There's a little bit more information about the semantics of these errors in RFC 2616, which documents HTTP 1.1.

Personally, I would probably use 400 Bad Request, but this is just my personal opinion without any factual support.

Answer 2

What exactly do you mean by "validation failure"? What are you validating? Are you referring to something like a syntax error (e.g. malformed XML)?

If that's the case, I'd say 400 Bad Request is probably the right thing, but without knowing what it is you're "validating", it's impossible to say.

Answer 3

400 Bad Request? Anyway it won't really matter, just pick one that makes sense. 401 is good too.

Answer 4

i would say technically it might not be an http failure, since the resource was (presumably) validly specified, the user was authenticated, and there was no operational failure (however even the spec does include some reserved codes like 402 Payment Required which aren't strictly speaking http-related either, though it might be advisable to have that at the protocol level so that any device can recognize the condition).

if that's actually the case, i would add a status field to the response with application errors, like

<status><code>4</code><message>Date range is invalid</message></status>

Answer 5

If "validation failure" means that there is some client error in the request, then use HTTP 400 (Bad Request). For instance if the URI is supposed to have an ISO-8601 date and you find that it's in the wrong format or refers to February 31st, then you would return an HTTP 400. Ditto if you expect well-formed XML in an entity body and it fails to parse.

Richardson and Ruby's RESTful Web Services contains a very helpful appendix on when to use the various HTTP response codes. They say:

400 (“Bad Request”)
Importance: High.
This is the generic client-side error status, used when no other 4xx error code is appropriate. It’s commonly used when the client submits a representation along with a PUT or POST request, and the representation is in the right format, but it doesn’t make any sense. (p. 381)

and:

401 (“Unauthorized”)
Importance: High.
The client tried to operate on a protected resource without providing the proper authentication credentials. It may have provided the wrong credentials, or none at all. The credentials may be a username and password, an API key, or an authentication token—whatever the service in question is expecting. It’s common for a client to make a request for a URI and accept a 401 just so it knows what kind of credentials to send and in what format. [...]

Answer 6

Try to test and debug it using http tool such: this free HTTP testing tool to verify the HTTP status code return from the web when sending different HTTP Get or post: