4 ms·

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 serv

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/01/18/rescuing-rest.html http://intercoolerjs.org/2016/05/08/hatoeas-is-for-humans.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 https://www.youtube.com/watch?v=HOK6mE7sdvs

ben509 7y ago
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.
- ssijak 7y ago
  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
  - einrealist 7y ago
    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.
  - legulere 7y ago
    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.
  - ben509 7y ago
    > 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.
clintonb 7y ago
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.
- sk5t 7y ago
  "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.
  - vearwhershuh 7y ago
    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.
- vearwhershuh 7y ago
  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.

ben509 7y ago

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.

ssijak 7y ago
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
- einrealist 7y ago
  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.
- legulere 7y ago
  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.
- ben509 7y ago
  > 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.

clintonb 7y ago

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.

sk5t 7y ago
"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.
- vearwhershuh 7y ago
  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.
vearwhershuh 7y ago
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.