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

It's a perfectly valid thinking to map error situations in the validation process to meaningful HTTP status codes.

I suppose you send the XML file to your validation server as a POST content using the URI to determine a specific schema for validation.

So here are some suggestions for error mappings:

• 200: XML content is valid
• 400: XML content was not well-formed, header were inconsistent, request did not match RFC 2616 syntax
• 401: schema was not found in cache and server needs credentials to use for authentication against the 3rd party SOA backend in order to obtain the schema file
• 404: Schema file not found
• 409: the XML content was invalid against the specified schema
• 412: Specified file was not a valid XMl schema
• 500: any unexpected exception in your validation server (NullPointerExceptions et al.)
• 502: the schema was not found in cache and the attempt to request it from the 3rd party SOA server failed.
• 503: validation server is restarting
• 504: see 502 with reason=timeout

Answer 2

I'd go with 400 Bad request and a more specific message in the body (possibly with a secondary error code in a header, like X-Parse-Error: 10451 for easier processing)

Answer 3

From w3c: 400 = The request could not be understood by the server due to malformed syntax.

I wouldn't serve that up unless it was actually the case that the server could not understand the request. If you're just getting invalid xml, serve a 200 and explain why things are not working.

Regards Fake

Answer 4

Status code 422 ("Unprocessable Entity") sounds close enough:

"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. For example, this error condition may occur if an XML request body contains well-formed (i.e., syntactically correct), but semantically erroneous, XML instructions."

Answer 5

That sounds like a neat idea, but the HTTP status codes don't really provide an "operation failed" case. I would return HTTP 200 with an X-Validation-Result: true/false header, using the body for any text or "reason" as necessary. Save the HTTP 4xx for HTTP-level errors, not application-level errors.

It's kind of a shame and a double-standard, though. Many applications use HTTP authentication, and they're able to return HTTP 401 Not Authorized or 403 Forbidden from the application level. It would be convenient and sensible to have some sort of blanket HTTP 4xx Request Rejected that you could use.

Answer 6

Amazon could be used as a model for how to map http status codes to real application level conditions: http://docs.amazonwebservices.com/AWSImportExport/latest/API/index.html?Errors.html (see Amazon S3 Status Codes heading)