Earlier quoted context omitted.
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)…
This is why my HATEOAS APIs always return urls in the form " https://mysite.com/{SHA256 hash}", and a façade API looks up the actual path from the cached hash. Hardcode that , bitches.
API Design Guide
191–192 of 192 posts
Re: API Design Guide
#192Earlier quoted context omitted.
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)…
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 who…
I don't think that the supposed benefits of HATEOAS actually materialise, in the real world.