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

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.