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