3 ms·

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.

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.

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.