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

Answer 1

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://tools.ietf.org/html/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

Answer 2

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 abc@invalid.org" 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 3

I think as long as you aren't misusing a code for something it was not intended then it really comes down to preference and opinion. A 409 is probably ok to use for validation failure although I think I personally would prefer a 200 with the validation error as a response. I think this makes it easier for developers to check for the common communication errors such as 401 or 500 and deal with them before they have to worry about validating the data they sent.

Answer 4

If the state of your HTTP resource is somewhere "between start and finish" to paraphrase your words on this admittedly older question, I would like to put a vote in for returning status 202. It has the advantage of being a 2-- "success" type response so a dumber client will not consider it a broken page, and its stated purpose in the HTTP 1.1 spec sounds like what you want (though many of the status code definitions are very ambiguous).

Specification Link

Excerpt:

202 Accepted

The request has been accepted for processing, but the processing has not been 
completed. The request might or might not eventually be acted upon, as it 
might be disallowed when processing actually takes place...

The 202 response is intentionally non-committal. Its purpose is to allow a server 
to accept a request for some other process (perhaps a batch-oriented process 
that is only run once per day) without requiring that the user agent's 
connection to the server persist until the process is completed. The entity 
returned with this response SHOULD include an indication of the request's 
current status and either a pointer to a status monitor or some estimate of 
when the user can expect the request to be fulfilled.

Answer 5

As is often the case it's hard to advise precisely without knowing exactly what you are doing, how, and why etc. For example:

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

Is this service serving local code? If so you should throw an exception to local code or return something normal.
Is it tied to an API request? If so on face value I can't see why you'd validate on a separate REST call rather than doing it all in one request.

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

I'm making assumptions for example's sake, but eg you can just let them make the request which they would if they had all the necessary data etc, and validate at that point.

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.

This is why I'm suggesting what I have, as your above reads like the requirement is:

1. Send request to API, API performs Validation and returns a response;
2. If response shows valid then user sends the next response to do the actual thing;
3. If response shows invalid then user has to do something and retry until they get a valid response then they still have to do the actual thing;

Alternative:

1. Send request to API, perform validation, if valid do the thing, else return response indicating invalid state;
2. User makes changes and again just has one request to send to do validation and the actual thing;

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.

If this isn't any kind pf remote/API request then I would suggest not using HTTP codes. Is this just all done within the same codebase? If so exceptions or bools etc from your validation to serve a message to the user.