Is a 422 response ever appropriate for a GET request?

Question

https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/422

The HyperText Transfer Protocol (HTTP) 422 Unprocessable Entity response status code indicates that the server understands the content type of the request entity, and the syntax of the request entity is correct, but it was unable to process the contained instructions.

I think an example of this would be a client sending a POST with an "Customer" object that has a mailing address that has a state (as in states in America) that doesn't exist.

Since a GET request isn't going to be processing anything (vs. a POST) it seems like a 404 is more appropriate if a query results in an entity not found. Conversely a 404 would never be appropriate for a POST.

But hey maybe I have it wrong and need to be educated. I ask because I did a GET to one of our APIs the other day and I got a 422 back and I'd never seen that happen before.

Answer 1

The 422 status code was added by WebDAV and is seen extremely rarely in vanilla HTTP. More often, a 400 Bad Request status code would be used, even though it is less specific.

GET requests can technically include a request body, for example to make a more complex query than what can be put into an URL due to length limits. However, a lot of software doesn't support this, and POST requests are commonly used in that role.

WebDAV doesn't overload GET like this. In addition to extra status code, it also defines extra HTTP methods for operations with special semantics.

In conclusion, the question “Is a 422 response ever appropriate for a GET request?” can be answered as:

• not really (it's a WebDAV-ism, and GET don't typically contain a request entity AKA request body)
• but it's legal, and client software should generally understand generic 4xx errors

Answer 2

The HTTP standard describes a situation where a 422 response can be used:

For example, this error condition may occur if an XML request body contains well-formed (i.e., syntactically correct), but semantically erroneous, XML instructions.

(emphasis mine)

Source: https://datatracker.ietf.org/doc/html/rfc4918#section-11.2

The key words here are "request body" and "semantically erroneous". For instance, if the request body contains syntactically correct XML, but one of the tags is not supported by the application processing the request, then the server can return a 422.

Consider another use case where you support file uploads, but for security reasons you do not want GPS coordinates in the image meta data. Even though the image data in the request body conforms to the JPEG file format, because someone uploads a photo with lat/lon coordinates the server could return a 422 response (we will, for a moment, pretend there is a valid reason the server rejects the request instead of stripping that meta data out).

A 422 response is more typically associated with a POST that accepts data in a specific format in the body of the request.

While GET requests do not typically include a body, arbitrary data can be passed in the query string. You could pass JSON or XML as a query string parameter if it is URL-encoded.

If you do this, I suppose a 422 response might be acceptable if the XML is syntactically correct, but contains tags that are not supported by the application interpreting the query.

I'm not sure how I would expect a server to respond in this situation, because passing XML or JSON in a query string is already an atypical workflow. I would be very surprised to find a GET request that accepts XML or JSON as a query string parameter to begin with, however I have done this before to support cross-domain "AJAX" before browsers supported this. Anyone remember JSONP?

I know one thing for sure: I would be very, very surprised if GET /something.html returned a 422.

Answer 3

Ok, GET Request is typically designed not to support a Request Body. But there is no protocol level restriction on this. This means you could send a request body with a GET Request.

As an Example, consider Elastic API: https://www.elastic.co/guide/en/elasticsearch/guide/current/_empty_search.html#get_vs_post

In this scenario, you could possibly return 422 for some Unprocessable Entities in the request body.