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.
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.
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:
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).
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.
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.
来源：https://stackoverflow.com/questions/11257470/is-returning-http-409-appropriate-for-a-validation-check