Hacker News Reader

Comment by vearwhershuh | Hacker News Reader

The primary innovation in REST is HATEOAS (which isn't mentioned in the document at all.) JSON isn't a hypertext, it just isn't a good format for REST-ful services.

http://intercoolerjs.org/2016/01/18/rescuing-rest.html

http://intercoolerjs.org/2016/05/08/hatoeas-is-for-humans.ht...

Doesn't anyone notice this? I feel like I'm taking crazy pills.

https://www.youtube.com/watch?v=HOK6mE7sdvs

View on HN

The trouble with HATEOAS is that it requires extra work on the client. The client is supposed to start at the root of the API, request URLs, and cache them. Getting the data one wants requires multiple HTTP calls, many of which are supposed to be cached.

I tried implementing this and found it toilsome. It was far easier to use versioned URLs that followed a documented pattern.

When I checked about three years ago there wasn’t much in the open source community that I could build atop for clients. I also didn’t want to maintain an SDK client in addition to the API itself.

"Toilsome" is probably the most kindly yet still accurate thing one could say about exposing HATEOAS to the real world, at this particular point in time.

Every 1.0 web app developer in the world implemented HATEOAS to a great extent without even thinking about it.

It's only toilsome when you try to shoe-horn it into a traditional data API, rather than accept it as a unique descriptive aspect of the early web architecture.

It's all a category error. HATEOAS was descriptive, he was describing the early web architecture, and it was implemented without thinking about it in web 1.0 apps.

It only became problematic when we tried to shoe-horn it into traditional data APIs.

So that's what HATEOAS is. I had been wondering why the Github APIs had these absurdly large responses with a shit-ton of urls.

> JSON isn't a hypertext, it just isn't a good format for REST-ful services.

The point of REST was to take ideas from the browser and apply them to other services.

But HATEOAS is proving that REST only really makes sense if you've got a browser on the other end.

> Doesn't anyone notice this? I feel like I'm taking crazy pills.

The first comment I saw on this article was, _every single person writing a REST api should have to memorize this table_.

If you were trying to sell people on a new library and said, "everyone here has to memorize this table," you'd get laughed at as a crazy person.

No, HATEOAS is not for humans but was imagined for api consumers. All those links that you mentioned in the Github api responses are named and you as a client can use them, where the actual url can change. Also, you as an api consumer can know what actions are available.

That being said, I have never seen developing api client driven mainly by HATEOAS

Imagine an API returning HTML, too. I've built such APIs (not public). I consider it best practice. The HTML representation can be utilized as the frontend. At least, its the interactive documentation to the API. In fact, when I built such APIs, I usually started with the HTML representation.

But isn’t almost always the link just the current link + the link name?

Apart from being able to tell the client what functions they are allowed to use and a very superficial form of documentation I don’t really get the advantage of it.

> All those links that you mentioned in the Github api responses are named and you as a client can use them, where the actual url can change.

I think that's a good idea, just like REST and HATEOAS are both ideas trying to solve problems.

I'm just skeptical that it'd work in practice. It seems vanishingly unlikely that consumers will use it correctly enough that changing the URLs in that mechanism wouldn't result in making the breakage even more mysterious.

When I say "it only makes sense if you've got a browser on the other end," the issue is you need a client approaching the complexity of a browser to do all the redirection and such that makes this level of flexibility for the API implementer to work.

I believe something like that is possible, but this isn't the way.

Reply on news.ycombinator.com