[treis]

>And who's to say you can't put the reason in the body and still keep the code?

Often systems will have application wide error handling to catch that and handle it in a systemic way. It can be a pain to short circuit that in a customizable off the shelf applications like Salesforce.

Philosophically, 4XX means the client did something wrong. Sending invalid data to a validation service is not doing something wrong.

[sagichmal]

> Philosophically, 4XX means the client did something wrong. Sending invalid data to a validation service is not doing something wrong.

The precise definition of 400 Bad Request is

    The 400 (Bad Request) status code indicates that the server cannot or
    will not process the request due to something that is perceived to be
    a client error (e.g., malformed request syntax, invalid request
    message framing, or deceptive request routing).

There's some room for interpretation for the phrase "process the request". If the only job of the service is to validate the request and return Valid or Invalid, then I guess yeah even an invalid request will have been processed, and 400 Bad Request may not be totally right. I think you could make a case for it! But I think you could also make a case for 200 OK with a more detailed error message and code in the body.

But if the service both validates the request and _then_ does something more substantial with it, I think 400 Bad Request is probably the most appropriate response to something that fails at step one.