So, to address this on its own terms, talking about HTTP as an 'application programmer', ignoring browsers and REST and the whole value add of the HTTP stack in

So, to address this on its own terms, talking about HTTP as an 'application programmer', ignoring browsers and REST and the whole value add of the HTTP stack in terms of caching and security and content negotiation... just thinking of HTTP as a way for a client to call a server and get back a message: This approach is the HTTP-server equivalent of exposing a function that sometimes returns null. When you call a function like that in your code, the call succeeds and returns, but the caller needs to now inspect the returned object to see if it is actually useful. In this case, the HTTP call succeeds, but you now have to parse the result to figure out whether you got something useful. In code, there are a few alternatives to having a function returning null: throwing an exception, the null object pattern, or the optional type/maybe monad. Using an HTTP status code lets your client choose an HTTP client implementation that manifests as one of these, according to their preference, simplifying their code. So just from an application design point of view... if you wouldn't build a function with that return signature, why would you build an HTTP endpoint that does that?