4 ms·
> then this script will have to "know in advance" how the API works anyway, and the "self-discoverability" of HATEOAS doesn't bring any benefit. Tentatively, i
by Joker_vD 2y ago
> then this script will have to "know in advance" how the API works anyway, and the "self-discoverability" of HATEOAS doesn't bring any benefit.
Tentatively, it allows better flexibility in non-entrypoint URIs, by adding a layer of indirection: instead of hardcoding URLs itself, you hardcode the name of the fields in the response that will contain actual URIs to follow.
But then there is a whole crowd of people who claim that URIs should never change anyhow, for any reason, in the first place.
- xg15 2y agoThat makes sense, but then it also trusts that every client will "play by the rules" - first do the "discovery" request, then use the discovered URL to do the real request - when they could just "cheat" and hardcode the URL. I think, again the incentives are misaligned, because hardcoding would be beneficial for the client devs in several ways: It's simpler to code, halves the number of requests at runtime and gets rid of several edge cases that you'd have to deal with - e.g. what happens if the discovered URL points to a different domain than the entrypoint? It makes sense from the server's POV, but because of this, I see a hard time to convince client devs to adopt it.
- Joker_vD 2y ago> e.g. what happens if the discovered URL points to a different domain than the entrypoint? You follow it. Not sure why even mention it: having a web of URLs spread between e.g. contoso-streaming.tv, api.contoso.com, login.contoso.org, etc. is nothing special these days.