[ACCEPTED]-Proper use of HTTP status codes in a "validation" server-http-status-codes

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

"The 422 (Unprocessable 11 Entity) status code means the server understands 10 the content type of the request entity (hence 9 a 415(Unsupported Media Type) status code 8 is inappropriate), and the syntax of the 7 request entity is correct (thus a 400 (Bad 6 Request) status code is inappropriate) but 5 was unable to process the contained instructions. For 4 example, this error condition may occur 3 if an XML request body contains well-formed 2 (i.e., syntactically correct), but semantically 1 erroneous, XML instructions."

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

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

So 1 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

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

POST /validator Content-type: application/xml

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

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

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

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

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

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

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

Regards Fake

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