Before REST gained mind share, developing for the web was effectively templating. Vanilla PHP, Java server pages, Django, Rails, etc all had this idea that business logic would be transformed server-side into complete web pages by injecting variables into HTML.

REST came along and tried to put some discipline around this. The URLs now mattered and had semantic meaning! All the self-describing hypertext stuff was interesting but largely ignored.

That one point - giving URLs noun-like semantics - led to the realization that the return mimetype could be anything. We could treat the website like a database and fetch raw information from it.

The only thing REST and JSON HTTP Apis have in common is that they agree URLs should have semantics. REST sorta opened peoples eyes to that fact... and the term was incorrectly adopted to describe everything that came after.

In addition to what you said, the idea that the endpoint should determine state and drive the possible sequence of actions is not obviously universally a good thing.

Many projects involve stringing together capability from different systems (via their api's) and creating essentially a new business layer on top of the combination of those systems. Now the abstract high level state is really managed by the new system and the component systems are just providing foundational capabilities.

The idea of HATEOS seems interesting but with limited application.

[dead]