HATEOAS seems great if you look at it on the design perspective. You can navigate the whole API just by having the entry point. Seems great right.
The HATEOAS has been introduced to solve "discoverability" of API.
But in practice this don't really work. This would mean a client can't bookmark a link to a resource, but instead he would need to navigate the whole "state machine" to discover the hypertext of the said resource.
This has two problem on my perspective:
- It don't look like the WEB. It is like if each time i need to find a thread on hackernews, in need to go from the frontpage and navigate until i find the thread. Why not just bookmark the url of the post and be done with it.
- This HATEOAS just translate the issue: Instead of hardcoding the links, I will be hardcoding the Relations between resources.
So if the goal of this HATEOAS is to allow one day to use a single client API that will be able to work with any REST API, Rest assured we're not quite there yet. (pun intended)
The HATEOAS has been introduced to solve "discoverability" of API. But in practice this don't really work. This would mean a client can't bookmark a link to a resource, but instead he would need to navigate the whole "state machine" to discover the hypertext of the said resource. This has two problem on my perspective: - It don't look like the WEB. It is like if each time i need to find a thread on hackernews, in need to go from the frontpage and navigate until i find the thread. Why not just bookmark the url of the post and be done with it. - This HATEOAS just translate the issue: Instead of hardcoding the links, I will be hardcoding the Relations between resources.
So if the goal of this HATEOAS is to allow one day to use a single client API that will be able to work with any REST API, Rest assured we're not quite there yet. (pun intended)