7 ms·

How Did REST Come to Mean the Opposite of REST? (2022)

76 points by DeusExMachina 3y ago

mdaniel 3y ago
previously: How did REST come to mean the opposite of REST? - https://news.ycombinator.com/item?id=32141027 https://news.ycombinator.com/item?id=32141027 - July 2022 (383 comments)
coldtea 3y ago
Because nobody cares what REST meant "originally" or what Fielding had in mind. What people care about, and what did caught on because of that, is getting rid of XML and SOAP, and using JSON and lightweight web serving concepts for data endpoints.
ytdytvhxgydvhh 3y ago
Prescriptivism vs descriptivism. Sorry, descriptivism always wins.
- harwoodjp 3y ago
  Naive binary
paulddraper 3y ago
Wait until I tell you about Java Script.
lzsiga 3y ago
Afaik, SOAP is a subset of all webservices; the rest is REST (i.e. XML without SOAP and non-XML).
NelsonMinar 3y ago
This essay is great. I can see from the first comments that its point is entirely lost. Which is too bad; the core idea of Representational State Transfer is interesting and deserves to be respected separate from "HTTP but not SOAP". I built some of Google's first public APIs and we used SOAP, to match the onion on our belts. It never worked very well. I'm real glad that JSON over HTTP and other forms of RPC succeeded where SOAP failed. But it's a shame that Roy's ideas for REST got lost in all that.
- lolinder 3y ago
  Do you have any resources showing what an API client for a "true REST" system would look like? The #1 objection I've seen to REST as Fielding described it is that it seems to basically assume that the human is the API client. For example, this passage from Fielding: > A REST API should be entered with no prior knowledge beyond the initial URI (bookmark) and set of standardized media types that are appropriate for the intended audience (i.e., expected to be understood by any client that might use the API). From that point on, all application state transitions must be driven by client selection of server-provided choices that are present in the received representations or implied by the user’s manipulation of those representations. The idea of a computer application that has no context beyond an entry URL and a media type (text/html) is pretty hard for me and many like me to wrap our heads around. I can't imagine a system being written that doesn't know what the options will be and what shape the data will come in, and once you've hard coded that it's not obvious what you gain by sending URLs instead of IDs. I'm totally open to there being something I'm missing here, but every explanation of REST I've seen focuses exclusively on the shape of the server response and doesn't explain what an API client is supposed to do with the response and how REST avoids hard-coding client actions.
  - magicalhippo 3y ago
    > The #1 objection I've seen to REST as Fielding described it is that it seems to basically assume that the human is the API client. Reading the essay, it seems that is indeed the goal that the client is the human, so it would be weird for that to be an objection. If so, the objection then seems rather that a RESTful API is not terribly useful for a lot of systems. Which is fine, not everyone has to love hamburgers either. But yeah, I'd love to see a proper non-trivial example.
    - lolinder 3y ago
      The essay repeatedly uses the phrase "RESTful API", so it's natural for people to get confused when it advocates for things that are fundamentally incompatible with an API client.
  - 3y ago
vlovich123 3y ago
The Atlassian APIs have JSON responses with URL links throughout for further navigation. That would seem like it satisfies the stricter definition of REST without being HTML. But self-describing interfaces like that are only useful when interacting with people who are then deciding what next action to take. They are decidedly not what you want when interacting with programs where the semantic interpretation of information is hard-coded into the program. That's why at the same time, REST was taken as a call to action to formalize the server-side API that clients rely on so that your user-facing UI would use that API to generate the relevant HTML for the browser and the same API could be reused for 3p developers to rely on to build automation / additional products without increasing the maintenance area.
- fatnoah 3y ago
  Agree. I've built a bunch of stuff using those APIs and consuming those links is actually more work than not having them, IMHO. To find them, I have to look at response payloads, identify the field with the link, and then call that link to get additional details. A simple, documented resource to URL mapping would be easier to use. It comes at the cost of having to update code when resource locations change, but I've yet to see that happen outside of major API changes that break things in other ways that require code changes on my end.
- pmontra 3y ago
  I had to deal with one of those APIs in a project years ago and we did use the URLs that it sent us in the JSON responses. We could have hardcoded them but that would have made our client brittle, because it would fail anytime the devs of the server changed their mind on their endpoints. This means that an attack on that server could make us POST to or GET from another domain controlled by the attacker? Absolutely yes. I don't remember how we dealt with it. Maybe we fixed the host, or made some sanity checks. Anyway an attacker with that level of access could probably siphon out data in a less evident way.
  - Jasper_ 3y ago
    HTTP already has a method for redirecting the client if they use an out of date URL. Three of them, in fact.
cratermoon 3y ago
I wonder how many people reading here have taken the time to sit down with Fielding's original 2000 dissertation, analyze what he said, and understand it?
teeray 3y ago
> REST must be the most broadly misused technical term in computer programming history. I can’t think of anything else that comes close ahem Agile
- roynasser 3y ago
  Scrum is pretty high on the list too
- deleted 3y ago
  [deleted]
- watters 3y ago
  See also: * DevOps * Microservices * SOA * ACID * Observability Semantic diffusion, dilution, and drift are endemic in tech because terms are so frequently co-opted by opportunists who want to find a way to sell the concept as a product. What is interesting is that the first sentence is undermined by the second sentence, which is fairly reasonable compared to the first.
  - kelseyfrog 3y ago
    I think there's a pedagogical component too. The way that things are taught have an outsized impact in how people think things are done. This extends far beyond concepts. For example, and I've been guilty of this too, in data science, it's common for tutorials and examples to be use ipython/jupyter notebooks. This, however, should not be mistaken for "It's a good idea to use notebooks as part of the code-to-production pipeline." It's an easy mistake to make, and implicitly part of how AI/ML is taught.
fatnoah 3y ago
For me, it all comes done to ideological purity vs. what works. Everything exists on that continuum. REST as defined in Roy's dissertation is pure and beautiful, but the work of programmatically navigating such an API adds burden for no gain in the vast majority of use cases.
- mercutio2 3y ago
  I’m a huge fan of (the original meaning of) REST, but… I agree with you! REST is for building cooperating standards based systems. Almost nobody these days is particularly invested in building standards to have different companies with different clients and servers interoperate anymore, everyone is focused on customer acquisition and monetization. So there’s really not much point in creating and deploying solutions aiming at this kind of interoperable standard. The folks at Fastmail are still trying to do this, more power to them, but they’re swimming upstream, I think.
treflop 3y ago
The answer is simple… Sometimes you spend more time trying to make an API cleanly fit into a REST scheme than actually making the API. Sooo you say fuck it.
- jokethrowaway 3y ago
  Let's not throw the baby with the bath water. Level 2 REST is a huge step up (over RPC without resources) to have clear interfaces.
fabian2k 3y ago
I generally like the idea of a resource-oriented API, this seems pretty intuitive and useful. And that part mostly survived even in APIs that are otherwise nothing like the original REST idea. But many other parts of the original idea just don't seem useful enough to be worth the effort. And there are parts where I don't think pure REST has good solutions (or I'm not understanding REST well enough to know them), mostly around bulk actions. The moment you want to act on multiple instances of a resource you have to invent your own stuff, it doesn't fit well with the usual REST layout. And there are very good reasons to need this, just iterating over resources is not a solution in terms of performance and transactional behaviour.
bilsbie 3y ago
I wonder if they simply overplayed their hand pushing for the esoteric http verbs like put. People then pick and choose what they can ignore. Should have stuck with get and post IMO.
deleted 3y ago
[deleted]
rlili 3y ago
Just because the person who coined the term had something else in mind, doesn't mean that it is inherently better than what it became. The author also misses an important point: Most applications nowadays must have multiple UIs, e.g., not only HTML, but also iOS and Android. The current pattern of using JSON-RPC-style APIs serves this reality much better than "correct" REST, since it can be reused.
LudwigNagasena 3y ago
When I was learning webdev (around early 2010s) I was very confused about exactly that. I couldn’t even comprehend how and why API of a web service could or need to be RESTful in the proper sense of the word. HTML is the REST API of the web. It allows people to dynamically navigate webpages to get what they want. Most APIs don’t need to be REST and to follow HATEOS: no one is going to explore them on the spot. So it’s just RPC built upon HTTP semantics (and sometimes not even that when everything is just POST requests with weird URIs). Many tutorials back then explained what REST is and then explained what RESTful API is. And they seemed like two totally different things. I thought I am not getting something. Thankfully, at some point I realised that all those tutorials and people were just parroting bullshit. At best one could say that JSON over HTTP is REST-like compared, for example, to websockets.
jameshart 3y ago
It is frustrating that people don’t know what makes REST RESTful. But what’s weirder is why people seem to want to make things RESTful in the first place. Why has it become a signal of quality to claim something is ‘RESTful’? I mean, for which problems does a true, Fielding-style RESTful API and universal client model actually make sense? Fielding himself was describing the World Wide Web. Not a web application - he was talking about the entire ecosystem on which arbitrary web applications can be built. The web (when driven through a web browser, at least) is RESTful, no matter what you do on top of it. If you are not building your own universal application ecosystem of services and clients akin to browsers and web servers, you don’t actually need a REST architecture. You probably need an RPC architecture. But for some reason people have acquired a vague understanding that REST is ‘better’ than RPC. What they usually mean is that idempotent resource-verb based RPC APIs are a more compatible way of building applications within the REST architecture of the web than SOAP-like RPC APIs are.
- mercutio2 3y ago
  I think carefully defining and documenting different complex media types is incredibly valuable, at scales much smaller than “the whole internet”. For instance, I think IMAP, CalDAV, CardDAV, JMAP, RSS and other similar standards add a ton of value to people’s lives. If you build a true, extensible, REST in its original meaning system, you’re contributing to this grand vision of interoperable utility. But I also agree with you that building interoperable standards is hard work with negative ROI for investors who aren’t trying to commoditize a complement somewhere. And so the IETF dream isn’t getting a ton of investment these days.
jokethrowaway 3y ago
I was aware of the whole REST is not REST but it was fascinating to read the history behind it. I'm adding this to my list of "misinterpretation of a Fowler's article causes nonsense in the tech community", right before microservices
mercutio2 3y ago
Yet another retcon of REST that never once mentions MIME types, and thus missed the point. All this gobbledygook about HTML “being REST” is silly and doesn’t match how things were discussed at the time. HATEOAS is delivered by encouraging different resources to have different MIME types, and offering a service document that lets you know what all the resources available are with their associated MIME types. That’s it. It’s really not very complicated, EXCEPT of course that almost no one not intimately involved with the IETF ever bothers defining new MIME types. This is unfortunate! It would be great if everyone would go ahead and document how their resources work, and then maybe we really could deliver on the promise of REST. I do agree that reasonably consistent verbs and paths are pleasant things for folks reading and debugging HTTP traffic, but that’s about all they have to do with REST. But it’s unfortunate we keep getting these explanations that somehow fail to get at the core of the original meaning.
AdamH12113 3y ago
Another essay from the same site helped this make more sense to me. If your immediate reaction was "But my code doesn't know how to handle the links in the response!", check it out: https://intercoolerjs.org/2016/05/08/hatoeas-is-for-humans.html https://intercoolerjs.org/2016/05/08/hatoeas-is-for-humans.h...
- lolinder 3y ago
  HATEOAS as designed for humans makes sense, but then REST advocates should really stop calling what they're after a RESTful API and start calling it a RESTful UI. An API is widely considered to be the opposite of a UI—it's the interface that is directed at computers rather than humans. If the key principle of REST is one that is incompatible with computer clients, then a good starting point in a constructive dialogue would be to acknowledge that what they're really saying is that a RESTful API is an oxymoron.
  - mercutio2 3y ago
    This authors definition of HATEOAS as being “humans read some text” is bizarre and completely disconnected from what people were talking about at the time. Here’s how HATEOAS is supposed to be helpful for computers: 1. Out of band, humans create complex, useful, well defined media types that cover the space of the functionality they’re trying to define. These need to be well documented. This is where the whole thing falls down 2. Once you’ve got useful media types, you build servers that offer clients a “service document”, a collection of interesting resources (with resources potentially exposed with different media type representations, so newer better media types can be chosen when they’re created in the future, without needing to swap out your server) 3. Servers also define a variety of useful verbs they support, which can also expand over time REST depends heavily on (1). Since almost no one bothers to do (1), the whole project gets tarnished by people trying to do the later stuff and calling it REST.
  - eadmund 3y ago
    > If the key principle of REST is one that is incompatible with computer clients Don’t worry, it’s not. While some hypermedia is intended for humans, there is no reason a hypermedia might not be targeted at computers instead.
mixmastamyk 3y ago
Simply REST as a whole was impractical for machines. So folks took the 3/4 that was applicable and ran with it. REST—the good parts. What I don’t completely understand is why the hand-wringing about it for almost two decades? I gathered from discussion it’s because business folks kept using the term in job posts. Other words bastardized by the public like “agile” and “hacker” say hello. :-D
quasarj 3y ago
So call it RPC. The author is being pedantic, which is fine, we all are in our own ways. But the first example is clearly unusable to anyone with a quarter of a braincell, so who cares?

76 points by DeusExMachina 3y ago

previously: How did REST come to mean the opposite of REST? - https://news.ycombinator.com/item?id=32141027 https://news.ycombinator.com/item?id=32141027 - July 2022 (383 comments)

coldtea 3y ago

Because nobody cares what REST meant "originally" or what Fielding had in mind. What people care about, and what did caught on because of that, is getting rid of XML and SOAP, and using JSON and lightweight web serving concepts for data endpoints.

ytdytvhxgydvhh 3y ago

Prescriptivism vs descriptivism. Sorry, descriptivism always wins.

harwoodjp 3y ago
Naive binary

paulddraper 3y ago

Wait until I tell you about Java Script.

lzsiga 3y ago

Afaik, SOAP is a subset of all webservices; the rest is REST (i.e. XML without SOAP and non-XML).

NelsonMinar 3y ago

This essay is great. I can see from the first comments that its point is entirely lost. Which is too bad; the core idea of Representational State Transfer is interesting and deserves to be respected separate from "HTTP but not SOAP". I built some of Google's first public APIs and we used SOAP, to match the onion on our belts. It never worked very well. I'm real glad that JSON over HTTP and other forms of RPC succeeded where SOAP failed. But it's a shame that Roy's ideas for REST got lost in all that.

lolinder 3y ago
Do you have any resources showing what an API client for a "true REST" system would look like? The #1 objection I've seen to REST as Fielding described it is that it seems to basically assume that the human is the API client. For example, this passage from Fielding: > A REST API should be entered with no prior knowledge beyond the initial URI (bookmark) and set of standardized media types that are appropriate for the intended audience (i.e., expected to be understood by any client that might use the API). From that point on, all application state transitions must be driven by client selection of server-provided choices that are present in the received representations or implied by the user’s manipulation of those representations. The idea of a computer application that has no context beyond an entry URL and a media type (text/html) is pretty hard for me and many like me to wrap our heads around. I can't imagine a system being written that doesn't know what the options will be and what shape the data will come in, and once you've hard coded that it's not obvious what you gain by sending URLs instead of IDs. I'm totally open to there being something I'm missing here, but every explanation of REST I've seen focuses exclusively on the shape of the server response and doesn't explain what an API client is supposed to do with the response and how REST avoids hard-coding client actions.
- magicalhippo 3y ago
  > The #1 objection I've seen to REST as Fielding described it is that it seems to basically assume that the human is the API client. Reading the essay, it seems that is indeed the goal that the client is the human, so it would be weird for that to be an objection. If so, the objection then seems rather that a RESTful API is not terribly useful for a lot of systems. Which is fine, not everyone has to love hamburgers either. But yeah, I'd love to see a proper non-trivial example.
  - lolinder 3y ago
    The essay repeatedly uses the phrase "RESTful API", so it's natural for people to get confused when it advocates for things that are fundamentally incompatible with an API client.
- 3y ago

vlovich123 3y ago

The Atlassian APIs have JSON responses with URL links throughout for further navigation. That would seem like it satisfies the stricter definition of REST without being HTML. But self-describing interfaces like that are only useful when interacting with people who are then deciding what next action to take. They are decidedly not what you want when interacting with programs where the semantic interpretation of information is hard-coded into the program. That's why at the same time, REST was taken as a call to action to formalize the server-side API that clients rely on so that your user-facing UI would use that API to generate the relevant HTML for the browser and the same API could be reused for 3p developers to rely on to build automation / additional products without increasing the maintenance area.

fatnoah 3y ago
Agree. I've built a bunch of stuff using those APIs and consuming those links is actually more work than not having them, IMHO. To find them, I have to look at response payloads, identify the field with the link, and then call that link to get additional details. A simple, documented resource to URL mapping would be easier to use. It comes at the cost of having to update code when resource locations change, but I've yet to see that happen outside of major API changes that break things in other ways that require code changes on my end.
pmontra 3y ago
I had to deal with one of those APIs in a project years ago and we did use the URLs that it sent us in the JSON responses. We could have hardcoded them but that would have made our client brittle, because it would fail anytime the devs of the server changed their mind on their endpoints. This means that an attack on that server could make us POST to or GET from another domain controlled by the attacker? Absolutely yes. I don't remember how we dealt with it. Maybe we fixed the host, or made some sanity checks. Anyway an attacker with that level of access could probably siphon out data in a less evident way.
- Jasper_ 3y ago
  HTTP already has a method for redirecting the client if they use an out of date URL. Three of them, in fact.

cratermoon 3y ago

I wonder how many people reading here have taken the time to sit down with Fielding's original 2000 dissertation, analyze what he said, and understand it?

teeray 3y ago

> REST must be the most broadly misused technical term in computer programming history. I can’t think of anything else that comes close ahem Agile

roynasser 3y ago
Scrum is pretty high on the list too
deleted 3y ago
[deleted]
watters 3y ago
See also: * DevOps * Microservices * SOA * ACID * Observability Semantic diffusion, dilution, and drift are endemic in tech because terms are so frequently co-opted by opportunists who want to find a way to sell the concept as a product. What is interesting is that the first sentence is undermined by the second sentence, which is fairly reasonable compared to the first.
- kelseyfrog 3y ago
  I think there's a pedagogical component too. The way that things are taught have an outsized impact in how people think things are done. This extends far beyond concepts. For example, and I've been guilty of this too, in data science, it's common for tutorials and examples to be use ipython/jupyter notebooks. This, however, should not be mistaken for "It's a good idea to use notebooks as part of the code-to-production pipeline." It's an easy mistake to make, and implicitly part of how AI/ML is taught.

fatnoah 3y ago

For me, it all comes done to ideological purity vs. what works. Everything exists on that continuum. REST as defined in Roy's dissertation is pure and beautiful, but the work of programmatically navigating such an API adds burden for no gain in the vast majority of use cases.

mercutio2 3y ago
I’m a huge fan of (the original meaning of) REST, but… I agree with you! REST is for building cooperating standards based systems. Almost nobody these days is particularly invested in building standards to have different companies with different clients and servers interoperate anymore, everyone is focused on customer acquisition and monetization. So there’s really not much point in creating and deploying solutions aiming at this kind of interoperable standard. The folks at Fastmail are still trying to do this, more power to them, but they’re swimming upstream, I think.

treflop 3y ago

The answer is simple… Sometimes you spend more time trying to make an API cleanly fit into a REST scheme than actually making the API. Sooo you say fuck it.

jokethrowaway 3y ago
Let's not throw the baby with the bath water. Level 2 REST is a huge step up (over RPC without resources) to have clear interfaces.

fabian2k 3y ago

I generally like the idea of a resource-oriented API, this seems pretty intuitive and useful. And that part mostly survived even in APIs that are otherwise nothing like the original REST idea. But many other parts of the original idea just don't seem useful enough to be worth the effort. And there are parts where I don't think pure REST has good solutions (or I'm not understanding REST well enough to know them), mostly around bulk actions. The moment you want to act on multiple instances of a resource you have to invent your own stuff, it doesn't fit well with the usual REST layout. And there are very good reasons to need this, just iterating over resources is not a solution in terms of performance and transactional behaviour.

bilsbie 3y ago

I wonder if they simply overplayed their hand pushing for the esoteric http verbs like put. People then pick and choose what they can ignore. Should have stuck with get and post IMO.

deleted 3y ago

[deleted]

rlili 3y ago

Just because the person who coined the term had something else in mind, doesn't mean that it is inherently better than what it became. The author also misses an important point: Most applications nowadays must have multiple UIs, e.g., not only HTML, but also iOS and Android. The current pattern of using JSON-RPC-style APIs serves this reality much better than "correct" REST, since it can be reused.

LudwigNagasena 3y ago

When I was learning webdev (around early 2010s) I was very confused about exactly that. I couldn’t even comprehend how and why API of a web service could or need to be RESTful in the proper sense of the word. HTML is the REST API of the web. It allows people to dynamically navigate webpages to get what they want. Most APIs don’t need to be REST and to follow HATEOS: no one is going to explore them on the spot. So it’s just RPC built upon HTTP semantics (and sometimes not even that when everything is just POST requests with weird URIs). Many tutorials back then explained what REST is and then explained what RESTful API is. And they seemed like two totally different things. I thought I am not getting something. Thankfully, at some point I realised that all those tutorials and people were just parroting bullshit. At best one could say that JSON over HTTP is REST-like compared, for example, to websockets.

jameshart 3y ago

It is frustrating that people don’t know what makes REST RESTful. But what’s weirder is why people seem to want to make things RESTful in the first place. Why has it become a signal of quality to claim something is ‘RESTful’? I mean, for which problems does a true, Fielding-style RESTful API and universal client model actually make sense? Fielding himself was describing the World Wide Web. Not a web application - he was talking about the entire ecosystem on which arbitrary web applications can be built. The web (when driven through a web browser, at least) is RESTful, no matter what you do on top of it. If you are not building your own universal application ecosystem of services and clients akin to browsers and web servers, you don’t actually need a REST architecture. You probably need an RPC architecture. But for some reason people have acquired a vague understanding that REST is ‘better’ than RPC. What they usually mean is that idempotent resource-verb based RPC APIs are a more compatible way of building applications within the REST architecture of the web than SOAP-like RPC APIs are.

mercutio2 3y ago
I think carefully defining and documenting different complex media types is incredibly valuable, at scales much smaller than “the whole internet”. For instance, I think IMAP, CalDAV, CardDAV, JMAP, RSS and other similar standards add a ton of value to people’s lives. If you build a true, extensible, REST in its original meaning system, you’re contributing to this grand vision of interoperable utility. But I also agree with you that building interoperable standards is hard work with negative ROI for investors who aren’t trying to commoditize a complement somewhere. And so the IETF dream isn’t getting a ton of investment these days.

jokethrowaway 3y ago

I was aware of the whole REST is not REST but it was fascinating to read the history behind it. I'm adding this to my list of "misinterpretation of a Fowler's article causes nonsense in the tech community", right before microservices

mercutio2 3y ago

Yet another retcon of REST that never once mentions MIME types, and thus missed the point. All this gobbledygook about HTML “being REST” is silly and doesn’t match how things were discussed at the time. HATEOAS is delivered by encouraging different resources to have different MIME types, and offering a service document that lets you know what all the resources available are with their associated MIME types. That’s it. It’s really not very complicated, EXCEPT of course that almost no one not intimately involved with the IETF ever bothers defining new MIME types. This is unfortunate! It would be great if everyone would go ahead and document how their resources work, and then maybe we really could deliver on the promise of REST. I do agree that reasonably consistent verbs and paths are pleasant things for folks reading and debugging HTTP traffic, but that’s about all they have to do with REST. But it’s unfortunate we keep getting these explanations that somehow fail to get at the core of the original meaning.

AdamH12113 3y ago

Another essay from the same site helped this make more sense to me. If your immediate reaction was "But my code doesn't know how to handle the links in the response!", check it out: https://intercoolerjs.org/2016/05/08/hatoeas-is-for-humans.html https://intercoolerjs.org/2016/05/08/hatoeas-is-for-humans.h...

lolinder 3y ago
HATEOAS as designed for humans makes sense, but then REST advocates should really stop calling what they're after a RESTful API and start calling it a RESTful UI. An API is widely considered to be the opposite of a UI—it's the interface that is directed at computers rather than humans. If the key principle of REST is one that is incompatible with computer clients, then a good starting point in a constructive dialogue would be to acknowledge that what they're really saying is that a RESTful API is an oxymoron.
- mercutio2 3y ago
  This authors definition of HATEOAS as being “humans read some text” is bizarre and completely disconnected from what people were talking about at the time. Here’s how HATEOAS is supposed to be helpful for computers: 1. Out of band, humans create complex, useful, well defined media types that cover the space of the functionality they’re trying to define. These need to be well documented. This is where the whole thing falls down 2. Once you’ve got useful media types, you build servers that offer clients a “service document”, a collection of interesting resources (with resources potentially exposed with different media type representations, so newer better media types can be chosen when they’re created in the future, without needing to swap out your server) 3. Servers also define a variety of useful verbs they support, which can also expand over time REST depends heavily on (1). Since almost no one bothers to do (1), the whole project gets tarnished by people trying to do the later stuff and calling it REST.
- eadmund 3y ago
  > If the key principle of REST is one that is incompatible with computer clients Don’t worry, it’s not. While some hypermedia is intended for humans, there is no reason a hypermedia might not be targeted at computers instead.

mixmastamyk 3y ago

Simply REST as a whole was impractical for machines. So folks took the 3/4 that was applicable and ran with it. REST—the good parts. What I don’t completely understand is why the hand-wringing about it for almost two decades? I gathered from discussion it’s because business folks kept using the term in job posts. Other words bastardized by the public like “agile” and “hacker” say hello. :-D

quasarj 3y ago

So call it RPC. The author is being pedantic, which is fine, we all are in our own ways. But the first example is clearly unusable to anyone with a quarter of a braincell, so who cares?