Proper use of HTTP status codes in a “validation” server

Question

Among the data my application sends to a third-party SOA server are complex XMLs. The server owner does provide the XML schemas (.xsd) and, since the server rej

Answer 1

Say you're posting XML files to a resource, eg like so:

POST /validator Content-type: application/xml

If the request entity fails to parse as the media type it was submitted as (ie as application/xml), 400 Bad Request is the right status.

If it parses syntactically as the media type it was submitted as, but it doesn't validate against some desired schema, or otherwise has semantics which make it unprocessable by the resource it's submitted to - then 422 Unprocessable Entity is the best status (although you should probably accompany it by some more specific error information in the error response; also note it's technically defined in an extension to HTTP, WebDAV, although is quite widely used in HTTP APIs and more appropriate than any of the other HTTP error statuses when there's a semantic error with a submitted entity).

If it's being submitted as a media type which implies a particular schema on top of xml (eg as application/xhtml+xml) then you can use 400 Bad Request if it fails to validate against that schema. But if its media type is plain XML then I'd argue that the schema isn't part of the media type, although it's a bit of a grey area; if the xml file specifies its schema you could maybe interpret validation as being part of the syntactic requirements for application/xml.

If you're submitting the XML files via a multipart/form or application/x-www-form-urlencoded form submissions, then you'd have to use 422 Unprocessable Entity for all problems with the XML file; 400 would only be appropriate if there's a syntactic problem with the basic form upload.