Hacker News Reader

Comment by recursivedoubts | Hacker News Reader

Martin, if you are reading this, here's something you could do:

Revisit REST (and the Richardson Maturity Model[1]) and explain why REST has failed so spectacularly in the JSON API world.

It's worth doing because REST-ful hypermedia systems are using an interesting and distinctive network model, and most younger web engineers don't know much about it and end up using the client-server approaches that have become so common for modern web applications.

You are in a great (perhaps the best) position to respark interest in hypermedia and the REST-ful approach.

I have some thoughts on the matter[2][3][4], and would be happy to discuss.

[1] - https://www.martinfowler.com/articles/richardsonMaturityMode...

[2] - https://intercoolerjs.org/2016/01/18/rescuing-rest.html

[3] - https://intercoolerjs.org/2016/05/08/hatoeas-is-for-humans.h...

[4] - https://htmx.org/essays/hypermedia-apis-vs-data-apis/

View on HN

He can start by actually developing a major (non-toy) application using HATEOAS and then once we all marvel at his success, we might consider doing things this way.

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 doesn't want you to reinvent the web browser.

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.

Yes, but there were some people that were pushing HATEOAS for APIs. I think the fact that pretty much no one does it is good enough evidence to see that it's just not a good fit. HATEOAS is good for web sites and human operators, but not for APIs being executed by software.

> explain why REST has failed so spectacularly in the JSON API world

Could you elaborate on this?

By failed, I think they mean “spectacularly wide usage, with some drawbacks”.

REST as Fowler advocated for is used approximately nowhere. The widely used thing known as REST is very unlike it.

Everyone hates HATEOAS

I've only heard of HATEOAS from people loving it but not getting to 'do' it.

Rather, perhaps people should take a look at the thoughts about REST from the researcher who wrote the original dissertation: https://roy.gbiv.com/untangled/2008/rest-apis-must-be-hypert...

"I am getting frustrated by the number of people calling any HTTP-based interface a REST API. "

I am familiar with that feel.

Someone please help here, im reading all the links here and still drawing a blank on what is and is not REST! Can someone link to an API that’s truly RESTful? And perhaps one that’s barely not?

REST is the architectural style of the World Wide Web: browsers reading cached copies of web pages that link to other web pages.

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.

> So almost any site you hit with your browser is a "RESTful API".

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.

There are some example links in this post about HATEOAS

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

REST has 6 constraints, the 6th constraint has 4 elements, the last of those four is a useless thing called HATEOAS.

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.

I think HATEOAS is basically requiring a client that looks a lot like a web browser. Which is no surprise, since Fielding is basically describing the way the web works. This is not necessarily a good prescription for APIs manipulated by code and not humans.

> spectacularly wide usage

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.

I wonder about this too. I regularly read that REST is bad/failed. But it appears to have had been widely adopted in a soft way, beating any competing ideas.

Mobile apps have high network latency and need multiple request/responses packaged into fewer server calls.

I think this is the main thing that prevents HATEOAS to be implemented. I'm very interested in it, but many "web apps" now needs more polished interaction and network resilience. I'm not saying it can't be done with an HTML-render centric codebase, but it's still uncommon.

Essentially no-one implements REST APIs as defined by Fielding and Fowler because what software developers and architects actually find valuable is an HTTP CRUD API. The widespread adoption of microsystems architectures required the selection and standardization of a format for the transfer and modification of resource representations between services, and CRUD over HTTPs serves that purpose pretty well.

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...

REST is a model for CRUD, but modern apps have far more complex interactions with server data.

This is a category error. REST is a novel network architecture, the most distinct aspect of which is the uniform interface[1], and has nothing to do, conceptually, with CRUD apps.

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

> REST is a model for CRUD

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.

Reply on news.ycombinator.com