4 ms·
The trouble with HATEOAS is that it requires extra work on the client. The client is supposed to start at the root of the API, request URLs, and cache them. Get
by clintonb 7y ago
The trouble with HATEOAS is that it requires extra work on the client. The client is supposed to start at the root of the API, request URLs, and cache them. Getting the data one wants requires multiple HTTP calls, many of which are supposed to be cached.
I tried implementing this and found it toilsome. It was far easier to use versioned URLs that followed a documented pattern.
When I checked about three years ago there wasn’t much in the open source community that I could build atop for clients. I also didn’t want to maintain an SDK client in addition to the API itself.
- sk5t 7y ago"Toilsome" is probably the most kindly yet still accurate thing one could say about exposing HATEOAS to the real world, at this particular point in time.
- vearwhershuh 7y agoEvery 1.0 web app developer in the world implemented HATEOAS to a great extent without even thinking about it. It's only toilsome when you try to shoe-horn it into a traditional data API, rather than accept it as a unique descriptive aspect of the early web architecture.
- vearwhershuh 7y agoIt's all a category error. HATEOAS was descriptive, he was describing the early web architecture, and it was implemented without thinking about it in web 1.0 apps. It only became problematic when we tried to shoe-horn it into traditional data APIs.