> Huh? HTTP is an application layer protocol.
I want to emphasise that "in this case" bit.
HTTP is an application layer protocol when the application in question in a webserver and nothing else.
In the case of REST, HTTP is simply a transport protocol. It is not necessary to use HTTP as the transport for RESTful applications. It's common, convention even, but not required.
> if you treat HTTP as the transport layer, what protocol does your application speak to the gateway?
WSGI, maybe? Sure, you can emit status codes there too, but it will be a different protocol you are talking over, not HTTP.
I've seen gRPC gateways for HTTP REST endpoints too.
> Is there some translation gateway that translates application-level semantics into HTTP ones?
I don't think we should be translating application status codes into HTTP status codes. I mean, sure, I've done it myself plenty of times, but it is a mixing of layers and a mixing of concerns.
The fact is, HTTP semantics are defined for (and in the context of) a webserver not an application server. That our application server is chatty with HTTP does not place it in the running context of a webserver.
The semantics of HTTP status codes makes absolutely no sense when emitted by an application.
You might argue that one of them (or maybe two, if we're being generous) such as "400 Bad Request" should be emitted by the application if (for example) a parameter is missing but even in that case it makes more sense for the application to send error-code/error-message so that more information can be given (such as which parameter is missing/invalid, etc).
If you're sending "400" status code for a missing parameter, how will the client know whether the HTTP request was malformed or whether the application input was mangled?
You can probably validate this theory with a basic time based analysis.