The use of 400 Bad Request

[Joshua Graham]

I'm seeing RESTful APIs using 400 Bad Request as a status that means something in the POST/PUT entity was invalid. Perhaps the entity was malformed, contained invalid attributes, or an attribute used a value that is not currently valid.

The HTTP spec is quite brief and vague about what constitutes a "bad request". It seems as though this status code, though, was intended for HTTP infrastructure ("servers") indicating there is something wrong with the request at the HTTP transport layer, for example, an HTTP header was too long, and the HTTP server was unable to do do anything with it.

I would expect that 409 Conflict and 422 Unprocessable Entity were better indicators of application semantics issues. It is true that 422 was for WebDAV but some of those could be quite useful in semantically rich, HATEOAS-driven integration.

Do you use 400 in your remote APIs, and are any uses not covered by 409 and 422?

Thanks,

Josh

[JoshG]

Sorry, that came from me (too many choices in "from" email address...)

[Jim Webber]

Hi Josh,

I've tended to use 400 in place of 422 since it's in HTTP rather than a dependent spec.

Jim