3 ms·

> It uses appropriate verbs... This shouldn't even be a thing to think about. HTTP verbs and error codes don't map well to many real use cases. You might argu

> It uses appropriate verbs... This shouldn't even be a thing to think about. HTTP verbs and error codes don't map well to many real use cases. You might argue that "GET" does map well to a query. However, you can't send a body with a GET, so you need to put that information in the URL, which is limited and causes other issues to consider. If we just admit that we're really doing RPC anyway, there is no point in using any other verb than "POST", passing in the arguments via the body, and returning any other codes than 200 and 400 with the result (or error) in the response. If we use JSON for this (as we likely already do), you have JSON-RPC. > You can make up a new acronym for it like "WNI" or Web Negotiation Interface, but it doesn't change anything that people care about. I actually care about it. The word REST forces us to think about irrelevant things, such as whether something should be a PUT or a POST, which error code maps best to an exception - only to end up with an API that is more annoying to implement, document and use. We would do well to transition out of of this insanity driven by buzzword compliance. If we managed to transition out of XML, we can do this too. > Have tires really changed that much in 200 years? Yes, they have! https://en.wikipedia.org/wiki/Tire#History https://en.wikipedia.org/wiki/Tire#History

andrewmcwatters 5y ago
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. You can’t get frustrated that HTTP isn’t a raw socket. 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. You end up rebuilding things that already exist. It’s a waste of time.
- incrudible 5y ago
  > 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.
Spivak 5y ago
So not only do they not map cleanly to actual applications but if you intermix your app's request statuses and error codes you don't have any way to distinguish an error in your application with an error in your transport. Does a 400 response mean that your HTTP is malformed or the that the app specific request payload is malformed? Depends on the app...

andrewmcwatters 5y ago

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. You can’t get frustrated that HTTP isn’t a raw socket. 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. You end up rebuilding things that already exist. It’s a waste of time.

incrudible 5y ago
> 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.

Spivak 5y ago

So not only do they not map cleanly to actual applications but if you intermix your app's request statuses and error codes you don't have any way to distinguish an error in your application with an error in your transport. Does a 400 response mean that your HTTP is malformed or the that the app specific request payload is malformed? Depends on the app...