5 ms·

I'm a big believer that HATEOAS serves no actual purpose. Adding a layer of indirection is pointless - messages get bloated by URLs the client virtually never n

I'm a big believer that HATEOAS serves no actual purpose. Adding a layer of indirection is pointless - messages get bloated by URLs the client virtually never needs. For the vast majority of APIs, URL structures don't change that often and, when they do, it often indicates changes to content being transmitted, which would require business logic updates anyway. For making APIs forward/backward compatible, both GraphQL and Protobufs are better options.

recursivedoubts 5y ago
As with many other comments in this thread, I agree with you, but only in terms of JSON APIs. The article is an attempt to explain HATEOAS in terms of HTML (or hypermedia) where it has a purpose and, in fact, is simply the natural state of affairs.
- User23 5y ago
  I’m disappointed that the initial vision of the web where the user-agent is an editor and not a browser was abandoned. Playing around with Nyxt has given me a glimpse of how that might have looked.
hermanradtke 5y ago
The html on this page also contains URLs that you will never click. The real problem with HATEOAS for JSON APIs is that we have never built the proper client. With html, you can rewrite your entire website and the browser will happily render the new pages. When people start writing such a client for JSON, the JSON starts to look very similar to html.
- pas 5y ago
  > [...] the JSON starts to look very similar to HTML. So that means, in practical terms, that every system that complies with the REST principles ends up virtually isomorphic to the web? Which kind of means that the REST principles are not general enough?
- camgunz 5y ago
  That's interesting. That makes me think of all the times a frontend engineer has tried to get me to put display logic in backend APIs. Their arguments were: - We can update the site without deploying code changes - These configurations can be actual configurations in our administration site, vs. code in the frontend - Dramatically simplifies the frontend My counterarguments were: - it doesn't make any sense to `GET /songs&limit=50&offset=1000` and also get ordering information or what have you, which changes the mental model from data store to application state store - we're not lowering complexity, we're just shifting presentation information to the backend where it certainly doesn't belong (imagine having to list songs in two different places that are presented differently--is that a different endpoint, a `scene` parameter, blah blah blah) - this information almost never changes But taken to its (I guess) logical conclusion here, where there's a sufficiently smart generic HATEOAS frontend, it's pretty cool? But I also guess it's not really different. Something has to know what order the buttons are in. If we're looking at the chain of a web stack, we have: [DB] -> [API] -> [Frontend] Doesn't it just seem like presentation stuff goes where we do the presenting? I think people's issue with HATEOAS is that we actually wanted an RPC backend where frontends control every aspect of the presentation, and HATEOAS wasn't just extra bloat, it put a straightjacket on design and asked backend engineers to start sending HTML again.
  - AmericanBlarney 5y ago
    You could probably do it and maintain clean separation of logic vs presentation but what's the benefit? I don't really think producers or consumers want a generic frontend - it's main utility seems like it would be for automated crawling, but there are plenty of other ways to handle that.
- AmericanBlarney 5y ago
  That would essentially be Postman or some other API testing tool. The thing is, very few people have any interest in browsing pure data. HATEOAS for JSON is especially useless given the same information can be derived from an API spec like Swagger, without the bloat of embedding reference URLs in every response.

recursivedoubts 5y ago

As with many other comments in this thread, I agree with you, but only in terms of JSON APIs. The article is an attempt to explain HATEOAS in terms of HTML (or hypermedia) where it has a purpose and, in fact, is simply the natural state of affairs.

User23 5y ago
I’m disappointed that the initial vision of the web where the user-agent is an editor and not a browser was abandoned. Playing around with Nyxt has given me a glimpse of how that might have looked.

hermanradtke 5y ago

The html on this page also contains URLs that you will never click. The real problem with HATEOAS for JSON APIs is that we have never built the proper client. With html, you can rewrite your entire website and the browser will happily render the new pages. When people start writing such a client for JSON, the JSON starts to look very similar to html.

pas 5y ago
> [...] the JSON starts to look very similar to HTML. So that means, in practical terms, that every system that complies with the REST principles ends up virtually isomorphic to the web? Which kind of means that the REST principles are not general enough?
camgunz 5y ago
That's interesting. That makes me think of all the times a frontend engineer has tried to get me to put display logic in backend APIs. Their arguments were: - We can update the site without deploying code changes - These configurations can be actual configurations in our administration site, vs. code in the frontend - Dramatically simplifies the frontend My counterarguments were: - it doesn't make any sense to `GET /songs&limit=50&offset=1000` and also get ordering information or what have you, which changes the mental model from data store to application state store - we're not lowering complexity, we're just shifting presentation information to the backend where it certainly doesn't belong (imagine having to list songs in two different places that are presented differently--is that a different endpoint, a `scene` parameter, blah blah blah) - this information almost never changes But taken to its (I guess) logical conclusion here, where there's a sufficiently smart generic HATEOAS frontend, it's pretty cool? But I also guess it's not really different. Something has to know what order the buttons are in. If we're looking at the chain of a web stack, we have: [DB] -> [API] -> [Frontend] Doesn't it just seem like presentation stuff goes where we do the presenting? I think people's issue with HATEOAS is that we actually wanted an RPC backend where frontends control every aspect of the presentation, and HATEOAS wasn't just extra bloat, it put a straightjacket on design and asked backend engineers to start sending HTML again.
- AmericanBlarney 5y ago
  You could probably do it and maintain clean separation of logic vs presentation but what's the benefit? I don't really think producers or consumers want a generic frontend - it's main utility seems like it would be for automated crawling, but there are plenty of other ways to handle that.
AmericanBlarney 5y ago
That would essentially be Postman or some other API testing tool. The thing is, very few people have any interest in browsing pure data. HATEOAS for JSON is especially useless given the same information can be derived from an API spec like Swagger, without the bloat of embedding reference URLs in every response.