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 rejects invalid XMLs with a meaningless message, I need to validate them locally before sending.
I could use a stand-alone XML schema validator but they are slow, mainly because of the time required to parse the schema files. So I wrote my own schema validator (in Java, if that matters) in the form of an HTTP Server which caches the already parsed schemas.
The problem is: many things can go wrong in the course of the validation process. Other than unexpected exceptions and successful validation:
- the server may not find the schema file specified
- the file specified may not be a valid schema file
- the XML is invalid against the schema file
Since it’s an HTTP Server I’d like to provide the client with meaningful status codes. Should the server answer with a 400 error (Bad request) for all the above cases? Or they have nothing to do with HTTP and it should answer 200 with a message in the body? Any other suggestion?
Update: the main application is written in Ruby, which doesn’t have a good xml schema validation library, so a separate validation server is not over-engineering.
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: