Is returning HTTP 409 appropriate for a validation check?

Question

I have a service where some validation rules must be checked before a particular operation should be able to take place.

For instance, the client should not generate printable reports if all of the validation rules are not being met.

However, an individual client may not have all of the required information (that user may only be able to access a subset of the data that is used to determine validation success), so a request must be sent to the server: basically "is a thing valid between start and finish".

The response will either be some sort of token that indicates VALID: FEEL FREE TO CONTINUE, or a list of validation failure reasons, that can be presented to the user.

It's obvious that a successful validation will return a 200 OK. But I don't feel that a success status code is appropriate for a validation failure. I'm leaning towards a 409 Conflict, but I've only ever used this to reject a PUT or POST. Is it valid (snicker) to have a validation failure indicated by a 409, or is there a better way?

Note: the action performed is not being performed on the server, so skipping this check, and just attempting the action, with a 403 in the case of the action being forbidden is not an option.

Answer 1

You've sent a request to the server for it to perform validation. It has successfully performed said validation. From an HTTP perspective, the request was well formed and correctly processed by the server.

So I'd say returning any HTTP error code would be incorrect.

---

This answer continues to receive downvotes and I'm not entirely sure why (none of the downvoters seem to leave any comments). Through a fair amount of back and forth with the OP, we established that the entire point of this request/response was to perform validation. The server received the request, it performed the validation that it was requested to perform, and it returned the results of that validation process to the caller.

There was absolutely nothing wrong with the client sending this request.

The server understood the request.

The request was valid (from an HTTP perspective).

The server could process the request.

The server performed 100% of the activity it was meant to and is returning the results that are produced having processed the request.

And that is why, as I say, I do not believe that an HTTP error code is appropriate.

I.e. imagine that the server exposes an endpoint that validates email addresses (for whatever particular form you wish to say that validation can be performed). It receives a request saying "validate [email protected]" and it produces a response saying "I took a look at this email address and I'd like you to tell the user that I can't get a valid DNS response for invalid.org". If people don't think a 200 response is correct here, I'd love to understand their reasoning.

Answer 2

While it is defined in a proposed standard still, 422 Unprocessable Entity is an appropriate status.

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.

References:

• https://www.rfc-editor.org/rfc/rfc4918#section-11.2
• http://developer.github.com/v3/#client-errors
• https://stackoverflow.com/a/2657624/247702
• http://en.wikipedia.org/wiki/List_of_HTTP_status_codes#4xx_Client_Error