-1

There are a lot of discussions if the HTTP request payload is missing mandatory attributes, the response code must either be 400 or 422.

I am yet not clear about the difference.

Please suggest with logical scenarios/examples when to use 400 or 422 HTTP status code.

Harpreet
  • 1,527
  • 13
  • 25
  • Solution https://stackoverflow.com/questions/16133923/400-vs-422-response-to-post-of-data – Praveen Gehlot Jan 07 '20 at 13:11
  • 1
    Realistically, no client implementation is going to be programmed to care -- both are errors that cannot be automatically recovered from, neither will yield different results if the request is repeated, and both are 4xx errors, which is the important thing. The discussion on the absolutely, positively, most correctest value to use according to how the standard is interpreted is more one of purity of belief and use as a shibboleth. – Jeroen Mostert Jan 07 '20 at 13:19
  • 1
    _"There are a lot of discussions [...] I am yet not clear"_ - please start by mentioning what you've found, and what parts of that are not clear. – CodeCaster Jan 07 '20 at 13:35
  • Every thread of discussion mentions what is already written in the definition of these HTTP codes. The definitions are not well explanatory with the speicifc scenarios. I have encountered one scenario as mentioned in the description(case of missing mandatory attributes), I need to understand how to generalize the concept of using these http status codes for any scenario. – Harpreet Jan 07 '20 at 14:11
  • Consider the following: if you can't make a clear decision based on what's in the standard and people's interpretation of it, there will be other with the same problem. Hence, no matter what you decide, you're going to run into clients who expect you to do the opposite. In that vein, you're best off just picking something (and 400 is the most obvious in that case because every client is going to support it) and calling it a day until actual compatibility issues are demonstrated. It is far more important to document clearly and give descriptive errors than to get the error number exactly right. – Jeroen Mostert Jan 07 '20 at 15:00

2 Answers2

2

I know this question is nearly a year old, but thought I'd add an answer based on my own experience designing and building a very large API domain across nearly 400 microservices.

Ideally, APIs should follow Postel's Law and be tolerant of what it receives. This has helped us clarify when to use 400 and when to use 422.

In the answer above, we would see the example 400 response as a 422 response. Why? Because we're tolerant of an "unknown" property by ignoring it. But the required <date> field is missing so we would return a 422 containing an error indicating as a such.

A 400 response would be raised if the consumer sent through a JSON payload under the application/xml content type or if the XML request was invalid (ie. they had <date>2020-01-07</dat> field).

An advantage this approach has given us is that we can define a different response contract for 422 responses while allowing 400 responses to remain a fairly generic "WTF are you trying to ask?" responses. Our 422 responses contain a collection of error messages that list every request constraint or requirement that has been broken.

We've also found this approach to be particularly useful for our UX guys who can submit forms to APIs and get back a response with human-readable errors they can map straight back onto the form fields (ie. hitting submit and not having filled in a compulsory field will generate a 422 response with a message stating that property is required).

Wade Pearce
  • 31
  • 1
  • 2
-1

As far as I know, 400 is used for syntactially incorrect requests and 422 for semtically incorrect requests. If you expect a Request like

...
  <name>test name</name>
  <date>2020-01-07</date>
...

400 would be:

...
  <name>test name</name>
  <dateString>2020-01-07</dateString>
...

422 would be:

...
  <name>test name</name>
  <date>hello</date>
...

I only use 400, because 422 is not defined in HTTP/1.1 RFC7231

Community
  • 1
  • 1
Stefan Vikoler
  • 1
  • 1
  • _"syntactially incorrect"_ - that's the RFC 2616 text, and nowadays a way too narrow interpretation. RFC7231, which you link to, mentions _"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 message framing, or deceptive request routing)"_. A missing XML element and an extraneous XML element (`date` vs `dateString`) are both syntactically valid (in XML as well as HTTP). Both your examples would warrant a 400 as well as a 422 response. – CodeCaster Jan 07 '20 at 13:33