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