Proper use of HTTP status codes in a "validation" server

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

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

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)