422 Unprocessable Entity Explained
What is 422 Unprocessable Entity
?
A 422
status code occurs when a request is well-formed, however, due to semantic errors it is unable to be processed. This HTTP status was introduced in RFC 4918 and is more specifically geared toward HTTP extensions for Web Distributed Authoring and Versioning (WebDAV).
There is some controversy out there on whether or not developers should return a 400
vs 422
error to clients (more on the differences between both statuses below). However, in most cases, it is agreed upon that the 422
status should only be returned if you support WebDAV capabilities.
A word-for-word definition of the 422
status code taken from section 11.2 in RFC 4918 can be read below.
The
422
(Unprocessable Entity) status code means the server understands the content type of the request entity (hence a415
(Unsupported Media Type) status code is inappropriate), and the syntax of the request entity is correct (thus a400
(Bad Request) status code is inappropriate) but was unable to process the contained instructions.
The definition goes on to say:
For example, this error condition may occur if an XML request body contains well-formed (i.e., syntactically correct), but semantically erroneous, XML instructions.
400
vs 422
status codes
Bad request errors make use of the 400
status code and should be returned to the client if the request syntax is malformed, contains invalid request message framing, or has deceptive request routing. This status code may seem pretty similar to the 422 Unprocessable Entity
status, however, one small piece of information that distinguishes them is the fact that the syntax of a request entity for a 422
error is correct whereas the syntax of a request that generates a 400
error is incorrect.
The use of the 422
status should be reserved only for very particular use-cases. In most other cases where a client error has occurred due to malformed syntax, the 400 Bad Request
status should be used.
How to fix a 422 Unprocessable Entity
error?
To fix a 422 Unprocessable Entity
error isn't so cut and dry. The resolution path can very much differ for each scenario. However, as described above in the RFC definition of the 422
status, the error occurs when your data is incorrect; or for the lack of better terms, doesn't make logical sense.
Try reviewing your data to verify whether or not you may have incorrectly defined a particular piece of data in your request. If you're still unable to find out the issue, try asking around in a web development community (e.g. Stackoverflow) with an example snippet of your code to see whether or not others can pinpoint where the issue is.
Summary
In conclusion, the 422
status code isn't overly common anymore. As of RFC 7231, the 400 Bad Request
status code has gathered good traction and in most cases is used as a replacement to the 422
status. Although, if you have a very specific use-case where you are making use of WebDAV and need to return a status code for a request that was syntactically correct but semantically incorrect then you could make use of the 422
status code under those circumstances.