Roy Fielding's Misappropriated REST Dissertation
Where to start...<p>First, nowadays altering the DOM is way more responsive than loading a new page, so no one really wants HATEOAS -- not even users, but especially not the sites we like to visit because they don&#x27;t want to put out public APIs anymore.  For non-browser app APIs (public or private), well, they can be the same, just driven by JS when in-browser.  This... is sad.  But this is a fact of life now.  Just watch Tom Scott explain why the APIs went away, and when the APIs went away, so did HATEOAS (<a href="https:&#x2F;&#x2F;www.youtube.com&#x2F;watch?v=BxV14h0kFs0" rel="nofollow">https:&#x2F;&#x2F;www.youtube.com&#x2F;watch?v=BxV14h0kFs0</a>).<p>Second, there&#x27;s a lot of APIs that needn&#x27;t have anything more than one end-point -- no links to traverse, no HATEOAS.  For example, a certification authority can take a CSR and authentication and return you a certificate -- one end-point is all you need, and other than that, the API can be RESTful in every sense.  And then there&#x27;s APIs where links aren&#x27;t necessarily abundant or interesting.<p>Third, HTTP kinda sucks anyways if you&#x27;re dealing with databases.  There&#x27;s no nice RESTful way to construct transactions unless you put the RDBMS smarts into the client (JS again), which you can&#x27;t do if it means trusting the client (it does).  So right there, REST is broken anyways.  Sure, if you&#x27;re distributing your database, you need to deconstruct your transactions anyways, but you&#x27;re not going to trust a user-agent to get that right, and anyways, you can&#x27;t really do that with a HATEOAS interface.<p>Put another way: show us how to build a secure application with REST (including HATEOAS) that a) users will enjoy, b) companies want to build, c) with complex transactions.  If you do, we might all get our pitchforks out and protest for HATEOAS.  Searching for examples of HATEOAS, I don&#x27;t find much.  Sure, for proprietary, corporate apps HATEOAS can be meaningful, but even there, I suspect for devs it&#x27;s easier to just define APIs and drive all in-browser interaction via JS.