To me, HATEOAS always seemed like it wants me to basically re-invent the web browser. You know, the fact that basically no one does things this way may give you a hint on how actually useful it is.

HATEOAS is describing how the browser and HTML works.

It was the JSON API folks who (inappropriately) appropriated REST terminology that made folks feel like they had to shoehorn that concept into what is really RPC.

Could you elaborate on this?

Unfortunately, REST is the buzzword under which HTTP CRUD APIs were proposed and promulgated, so now we have a schism between theorists who consider HATEOAS a requirement but can't explain any benefit to the common real-world use case, or give any practical examples, and engineers who now just roll their eyes when the theorists say they're not really building REST APIs.

We know we're not, but if we tell our managers that we've implemented HTTP CRUD APIs for the backend services, they'll ask us why we're didn't choose REST...

I am familiar with that feel.

If you call your API REST, some zealots will open up your API and look if your beautiful response is polluted with any "links". If it is instead pristine, they will claim your API is not REST.

It's really ridiculous, the links system is only barely useful in some GUI data exploration tools, that are not even that comfortable to use.

If you use a JSON API that feels weirdly antiquated because of the superfluous fields, this is why. If you disregard HATEOAS basically every JSON API on the web is REST.

So almost any site you hit with your browser is a "RESTful API". Another decent example is Atom Syndication / Atom Publishing.

The best introduction that I've found is Jim Webber's 2011 talk https://www.youtube.com/watch?v=aQVSzMV8DWc&t=3m8s Jon Moore's 2010 Hypermedia APIs talk is also good https://vimeo.com/20781278

Unfortunately, a second idea appeared, that embraced the label "REST" but used it to mean something else (roughly, a set of conventions for how to organize web pages and the edits one makes to web pages). And the second idea was written and shared with a much larger audience than the first (in addition to being an "easier" idea), so it grabbed a super majority of the mind share.

I said something to that effect in a job interview once when the topic of REST came up. I was looked at like I had two heads.

https://engineering.3ap.ch/post/using-hateoas-with-rest/

I think the main distinction according to the original paper is if you are doing just HTTP CRUD ( not REST) or also HATEOAS

There are very few JSON-based hypermedia APIs being built and the few that were are almost never used as a uniform interface. They are treated as a normal, RTFM API.

In REST-ful terms (real REST, not the "REST is JSON with hierarchical end points, kinda" sense), REST has failed spectacularly in the JSON world.

CRUD covers all possible interactions with data, and, in that sense, this description is correct.

“CRUD application” is sometimes used to refer to an application which presents only the most simple operations data operations to users, and saying REST is for CRUD applications in that sense would be the opposite of the truth. In fact, its the opposite, its a mechanism which facilitates creating applications of arbitrary complexity from components exposing simple, self-describing interfaces.

It may be associated with web 1.0 CRUD apps, but the actual REST/hypermedia model generalizes and HTML, with a bit of help[2], can produce sophisticated UIs well beyond "CRUD".

--

[1] https://en.wikipedia.org/wiki/Representational_state_transfe...

[2] https://htmx.org/examples