5 ms·

Yes, correct. However, this relies on clients using your API in a hateos way - which they have to go out of their way to do: starting at /, reading the response

by dflock 10y ago

Yes, correct. However, this relies on clients using your API in a hateos way - which they have to go out of their way to do: starting at /, reading the responses, navigating down only using URLs that you return, etc... No clients bother to do this, in the real world - they just hard code/compose the URLs that they need to use. Why make extra http calls when you don't have to? Why parse all the json-hal (or whatever) to "figure out" which URL to call next, when you don't have to? Even if most clients did this, you can't enforce it, so not all of them will, so some will still break when you change URLs.

piaste 10y ago
This is why my HATEOAS APIs always return urls in the form "https://mysite.com/{SHA256 https://mysite.com/{SHA256 hash}", and a façade API looks up the actual path from the cached hash. Hardcode that, bitches.
- theptip 10y ago
  Haha, I have definitely considered that path, but 1) It makes manual testing annoying, 2) I have a nagging feeling that if my users are "doing it wrong" then maybe the API is doing it wrong... Also I've been playing with autogenerating client implementations using autogenerated swagger specs, and that approach is incompatible with an actual opaque linked API. It would be nice to have the best of both worlds.
- dflock 10y ago
  That seems rather user hostile.
theptip 10y ago
Very true - that is the best counterargument. However, we're still back to the worst-case here being the best case without HATEOAS, and well-behaved clients can still reap the benefits even if there are some misbehaving clients requiring multiple versions to be deployed in parallel. There's a good question about how long you can cache those URLs for as well; it's a non-starter for a client to have to traverse the whole tree from the root for every request. So can I cache the responses for the duration of my auth token, and get a new root node as part of my re-auth? If you go down that route, now you need to maintain two versions again during migration (but you do keep the ability for 'well-behaved' clients to migrate versions without downtime). As the sibling comment describes, you _can_ enforce this by obfuscating your URLs, but I've not had the guts to do that yet... Another approach would be to write great client libraries yourself, so that you know that the clients are consuming the API correctly.
- dflock 10y ago
  > well-behaved clients can still reap the benefits I don't think that the supposed benefits of HATEOAS actually materialise, in the real world.

by dflock 10y ago

piaste 10y ago

This is why my HATEOAS APIs always return urls in the form "https://mysite.com/{SHA256 https://mysite.com/{SHA256 hash}", and a façade API looks up the actual path from the cached hash. Hardcode that, bitches.

theptip 10y ago
Haha, I have definitely considered that path, but 1) It makes manual testing annoying, 2) I have a nagging feeling that if my users are "doing it wrong" then maybe the API is doing it wrong... Also I've been playing with autogenerating client implementations using autogenerated swagger specs, and that approach is incompatible with an actual opaque linked API. It would be nice to have the best of both worlds.
dflock 10y ago
That seems rather user hostile.

theptip 10y ago

Very true - that is the best counterargument. However, we're still back to the worst-case here being the best case without HATEOAS, and well-behaved clients can still reap the benefits even if there are some misbehaving clients requiring multiple versions to be deployed in parallel. There's a good question about how long you can cache those URLs for as well; it's a non-starter for a client to have to traverse the whole tree from the root for every request. So can I cache the responses for the duration of my auth token, and get a new root node as part of my re-auth? If you go down that route, now you need to maintain two versions again during migration (but you do keep the ability for 'well-behaved' clients to migrate versions without downtime). As the sibling comment describes, you _can_ enforce this by obfuscating your URLs, but I've not had the guts to do that yet... Another approach would be to write great client libraries yourself, so that you know that the clients are consuming the API correctly.

dflock 10y ago
> well-behaved clients can still reap the benefits I don't think that the supposed benefits of HATEOAS actually materialise, in the real world.