4 ms·

This is all pedantry. I don't think I've ever talked to a developer who cares. All people care about is whether or not you have a sane API to work with over HT

This is all pedantry. I don't think I've ever talked to a developer who cares. All people care about is whether or not you have a sane API to work with over HTTP. It uses appropriate verbs, maybe, and has meaningful endpoints and request and response objects you work with, hopefully. 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. There are bigger problems in the world. No need to keep redefining dirt. If you spend a considerable amount of time pondering such things, it's probably a sign that you need to be growing somewhere else in life and using those skills to enhance your existing ones. Have tires really changed that much in 200 years?

alephu5 5y ago
REST will be rebranded one day because our industry loves renaming old ideas and presenting them as new. I agree with you though, it's pointless.
- datavirtue 5y ago
  I think we rather realize that the original meaning was misconstrued and then have to use different terminology to describe the original idea because the original terms have been co-opted. It looks like an old idea being presented as new and indeed it is new to many.
Kinrany 5y ago
As it is, REST is not standardized enough for automation. It should be possible to generate a client library in any language just from the service's self-description.
- sitkack 5y ago
  The poetry of writing semantically meaningful urls is gone. We need really detailed descriptions of the interface boundary, who is responsible and how things are encoded, such that one can use any language they wish for either side of the call. This problem has been solved before.
- Kinrany 5y ago
  The article is in fact arguing that calling APIs RESTful is a category error. REST is a standard for protocols implemented by APIs, not APIs themselves. WWW itself is RESTful, not WWW servers.
Kinrany 5y ago
It's pedantry indeed, but in this case the incorrect use of words actively confuses people, causes arguments, and wastes time. You know this is the case whenever people are seriously considering references to the thesis as arguments.
incrudible 5y ago
> 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.
datavirtue 5y ago
Yeah, the ship has sailed. None of the points or pedant in this very informative article are ever going to matter.
shrimpx 5y ago
You and the article author basically agree but you insist that you can just say “hey let’s just get over it, guys!” instead of deconstructing it. But the root of the problem is a fundamental misunderstanding. It doesn’t work to just get over it when you don’t understand what “it” is.

alephu5 5y ago

REST will be rebranded one day because our industry loves renaming old ideas and presenting them as new. I agree with you though, it's pointless.

datavirtue 5y ago
I think we rather realize that the original meaning was misconstrued and then have to use different terminology to describe the original idea because the original terms have been co-opted. It looks like an old idea being presented as new and indeed it is new to many.

Kinrany 5y ago

As it is, REST is not standardized enough for automation. It should be possible to generate a client library in any language just from the service's self-description.

sitkack 5y ago
The poetry of writing semantically meaningful urls is gone. We need really detailed descriptions of the interface boundary, who is responsible and how things are encoded, such that one can use any language they wish for either side of the call. This problem has been solved before.
Kinrany 5y ago
The article is in fact arguing that calling APIs RESTful is a category error. REST is a standard for protocols implemented by APIs, not APIs themselves. WWW itself is RESTful, not WWW servers.

Kinrany 5y ago

It's pedantry indeed, but in this case the incorrect use of words actively confuses people, causes arguments, and wastes time. You know this is the case whenever people are seriously considering references to the thesis as arguments.

incrudible 5y ago

> 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.

datavirtue 5y ago

Yeah, the ship has sailed. None of the points or pedant in this very informative article are ever going to matter.

shrimpx 5y ago

You and the article author basically agree but you insist that you can just say “hey let’s just get over it, guys!” instead of deconstructing it. But the root of the problem is a fundamental misunderstanding. It doesn’t work to just get over it when you don’t understand what “it” is.