> As soon as you ignore HTTP constructs, you drop infrastructural benefits and the benefits of particular levels of abstraction reacting to those responses, whi

> As soon as you ignore HTTP constructs, you drop infrastructural benefits and the benefits of particular levels of abstraction reacting to those responses, which are often fully intended to be used. Can you turn this word salad into a real world example? If it's "you can cache GET requests through a proxy" or something of the sort: Fine, use HTTP GET for that. You don't need to do absolutely everything through RPC. Obviously, a web client using RPC needs to be shipped through HTTP GET, for instance. > If you didn’t care about any of that you might as well use websockets for everything. And then as soon as you do, you lose out on everything that requires an HTTP request/response. No. I'm fine with using HTTP for RPC. I'm fine with request/response, it maps well to RPC. What I have a problem with is shoehorning RPC into HTTP verbs and codes for literally no benefit. That's what distinguishes "real world REST" from the more reasonable JSON-RPC.