Menu
I am trying to build a RESTful web service which is supposed to power my UI. If I go by pure HATEOAS principles, I should only be exposing URIs of individual resources in collections. Now, say I have a a parent-child relationship, and each parent can have like 50 children, and the UI requires partial data for all the children also to be shown when the parent is clicked.
If I only expose child URIs with the parent, then the UI will have to make 50 web service calls to get this done. The other approach is to have a separate API which will give out the parent as well as partial info about the children instead of just the URIs. I am sure this is a common enough problem. What is the right balance here? What are some of the gotchas? The "only URI" approach is cleaner from a design perspective, but it could make the UI really slow and put a lot of load on the server because of all these service calls. So, the other approach might be more practical. In your experience, which is better?
824
Using HATEOAS (Hypermedia as the engine of application state) allows an API to define the control logic available to clients. It gives rise to a discoverable API where clients follow links embedded in resources rather than directly manipulating URLs.
HATEOAS is just one of the aspects that adds difficulty to a REST architecture. People don't do HATEOAS for all the reasons you suggest: it's difficult. It adds complexity to both the server-side and the client (if you actually want to benefit from it). HOWEVER, billions of people experience the benefits of REST today.
Why Do We Need HATEOAS? The single most important reason for HATEOAS is loose coupling. If a consumer of a REST service needs to hard-code all the resource URLs, then it is tightly coupled with your service implementation. Instead, if you return the URLs, it could use for the actions, then it is loosely coupled.
Suppose, we have requested a GET request for localhost:8080/users/1, it returns the details of user id 1. Along with this, it also returns a field called link that contains a link (localhost:8080/users) of all users so that consumers can retrieve all the users. This concept is called HATEOAS.
You are being misled about what the hypermedia constraint requires. There is nothing that says you cannot include information from your child objects in a representation of the parent object. In fact that's exactly what Hal (a hypermedia type) was designed to enable.
127
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With
