4 ms·

It seems like when taken to an extreme, strong HATEOAS would mean you could write a universal client that works across all APIs. I don't think service develope

It seems like when taken to an extreme, strong HATEOAS would mean you could write a universal client that works across all APIs. I don't think service developers take HATEOAS super-seriously. From what I've seen, returning resources with a URI rather than an identifier is about all many services do to be HATEOAS-ish. Clients are coupled to the server, but that's often okay.

discreteevent 4y ago
> strong HATEOAS would mean you could write a universal client that works across all APIs. It would be hard not to make that client behave like a browser from the user's point of view.
- marcosdumay 4y ago
  Exactly. HATEOAS implies as much flexibility as a browser, and as much understanding of the server data as a browser. So if you want a HATEOAS API, just make it output HTML and go with the crowd.
steve-chavez 4y ago
> It seems like when taken to an extreme, strong HATEOAS would mean you could write a universal client that works across all APIs. And if you go with HAL or JSON-LD, you have to use a specific clients for those formats, so not universal anyway. I tend to agree with "HATEOAS is for Humans"[1], HATEOAS makes sense when interacting with HTML. [1]: https://intercoolerjs.org/2016/05/08/hatoeas-is-for-humans.html https://intercoolerjs.org/2016/05/08/hatoeas-is-for-humans.h...