3 ms·
I very much disagree with this. This is both semantically wrong and unpractical at the same time. You can and probably should provide a payload for further pro
by dgb23 4y ago
I very much disagree with this. This is both semantically wrong and unpractical at the same time.
You can and probably should provide a payload for further processing in some cases, but that's an orthogonal concern.
You are also writing a HTTP server, which provides resources, expects certain formats, provides certain formats, tells intermediate layers and clients about what to cache for how long, says whether a new resource has been created or _will be_ created. You might be redirecting or you might be telling a client that they need to retry a request because there has been a conflict. Your response might be processed by different layers, some of which only care about the status codes, while others will inspect the payload to make further decisions. The list goes on.
Status codes are there so you can do all of these things and more in a standardized fashion. Even just from a human consumption perspective it is useful to just look at the code and immediately have an intuition of what happened.
Also many of the status codes make no sense at all if an application server doesn't provide them. A reverse proxy doesn't know whether there has been a transactional issue on the application server, so it cannot say 409 without that information. A caching layer doesn't know about the domain model so it cannot say whether a specific resource can be cached forever.
- that_james 4y agoI think the issue is here is that I should have explicitly stated this was about HTTP RPC (I am steering clear of REST for a reason). In the context of RPC, is it still impractical? It feels clearer to me, but I might just be continuing my own confusion now
- dgb23 4y agoMy comment makes sense if you lean on REST/HTTP and want to leverage the uniform communication and layered architecture. The more bespoke you get, the less you want to care about what I said above. I interpreted your post as general if that makes sense. In any case, consistency is key. Personally I think it is easier to lean on standards in order to be consistent. Which is why I made some examples of status codes that can only be formed by an application server. I think "how do I avoid surprises, workarounds and inconsistencies" is a good question to make decisions around what we're discussing here.
- dragonwriter 4y ago> In the context of RPC, is it still impractical? If you are defining a bespoke RPC protocol that incidentally uses some parts of HTTP without much concern about the spec but only concern with what existing infrastructure will do with requests, you have…lots of freedom to design things however you want. OTOH, a lot of work has gone into handling almost every conceivable aspect of information interchange, within a REST style (because REST was both derived from the architecture of the Web and used in updating HTTP for HTTP/1.1) in the HTTP standards (there are some gaps still, like that addressed by the draft QUERY [0] method), why reinvent the wheel, unless you are specifically dealing with use cases squarely within the gaps? [0] https://www.ietf.org/archive/id/draft-ietf-httpbis-safe-method-w-body-03.html https://www.ietf.org/archive/id/draft-ietf-httpbis-safe-meth...