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

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 &quot;HTTP but not SOAP&quot;.<p>I built some of Google&#x27;s first public APIs and we used SOAP, to match the onion on our belts. It never worked very well. I&#x27;m real glad that JSON over HTTP and other forms of RPC succeeded where SOAP failed. But it&#x27;s a shame that Roy&#x27;s ideas for REST got lost in all that.

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.<p>That&#x27;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 &#x2F; additional products without increasing the maintenance area.

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&#x27;t seem useful enough to be worth the effort. And there are parts where I don&#x27;t think pure REST has good solutions (or I&#x27;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&#x27;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.

For me, it all comes done to ideological purity vs. what works. Everything exists on that continuum.<p>REST as defined in Roy&#x27;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.

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

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’?<p>I mean, for which problems does a true, Fielding-style RESTful API and universal client model actually make sense?<p>Fielding himself was describing the World Wide Web. Not <i>a web application</i> - he was talking about the entire ecosystem <i>on which arbitrary web applications can be built</i>.<p>The web (when driven through a web browser, at least) <i>is</i> RESTful, no matter what you do on top of it.<p>If you are not building your own universal application ecosystem of services and clients akin to browsers and web servers, you don’t actually <i>need</i> a REST architecture. You probably need an RPC architecture.<p>But for some reason people have acquired a vague understanding that REST is ‘better’ than RPC.<p>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.

Prescriptivism vs descriptivism. Sorry, descriptivism always wins.

I was aware of the whole REST is not REST but it was fascinating to read the history behind it.<p>I&#x27;m adding this to my list of &quot;misinterpretation of a Fowler&#x27;s article causes nonsense in the tech community&quot;, right before microservices

previously:<p><i>How did REST come to mean the opposite of REST?</i> - <a href="https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=32141027">https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=32141027</a> - July 2022 (383 comments)

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

Another essay from the same site helped this make more sense to me. If your immediate reaction was &quot;But my code doesn&#x27;t know how to handle the links in the response!&quot;, check it out:<p><a href="https:&#x2F;&#x2F;intercoolerjs.org&#x2F;2016&#x2F;05&#x2F;08&#x2F;hatoeas-is-for-humans.html" rel="nofollow">https:&#x2F;&#x2F;intercoolerjs.org&#x2F;2016&#x2F;05&#x2F;08&#x2F;hatoeas-is-for-humans.h...</a>

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

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

When I was learning webdev (around early 2010s) I was very confused about exactly that. I couldn’t even comprehend how and why <i>A</i>PI of a web service could or need to be RESTful in the proper sense of the word. HTML <i>is</i> 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).<p>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.

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

Just because the person who coined the term had something else in mind, doesn&#x27;t mean that it is inherently better than what it became.<p>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 &quot;correct&quot; REST, since it can be reused.

Simply REST as a whole was impractical for machines. So folks took the 3&#x2F;4 that was applicable and ran with it. REST—the good parts.<p>What I don’t completely understand is why the hand-wringing about it for almost two decades?<p>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

Wait until I tell you about Java Script.

Because nobody cares what REST meant &quot;originally&quot; or what Fielding had in mind.<p>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.

Yet another retcon of REST that never once mentions MIME types, and thus missed the point.<p>All this gobbledygook about HTML “being REST” is silly and doesn’t match how things were discussed at the time.<p>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.<p>That’s it.<p>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.<p>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.<p>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.<p>But it’s unfortunate we keep getting these explanations that somehow fail to get at the core of the original meaning.

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