HATEOAS for reducing coupling

In any Client-Server architecture, there are basically two types of coupling: the data they exchange and the means of communication between both.

Any change in either the data structure or communication will affect the client. No matter how well the client was programmed, a refactor, either big or small, must be performed. And that's the nature of coupling.

But in the pursuit of loose coupling, HATEOAS offers a simple mechanism for reducing the coupling generated by communication.

HATEOAS stands for Hypermedia As The Engine of Application State. The basic idea is to use Hypermedia as the mechanism for the client to interact with the server.

Through the use of links, a client can obtain all the resources it needs. A link has a well-known structure that includes, at least, two fields: href holds a resource URI, and rel helps to understand which resource will be obtained. The whole interaction then is reduced to searching and following links.

But, how will the use of links help the client in reducing communication-related coupling?

Reducing communication coupling

Coupling with data structure is inevitable for a client. Let's use as an example a web store application. If the client needs to display a product name, it must use the field "productName" from the Product resource. If the field is changed to "name", the client must change.

But this inevitable coupling can be used as a benefit. As the client must know the data structure anyway, links to other resources can be included as part of the server response. So if the client needs to reach more resources, it only has to search for a specific link and follow it.

Suppose the client needs to display the reviews of a product. With HATEOAS, a link to the reviews list is included in the Product resource with a specific rel value.
 

           "id" : 1,
        "name" : "Some product",
        "links" : [  
                      {
                        "rel" : "reviews",
                        "href" : "http://mystore/products/1/reviews,
                      }
                    ]

In order to get the reviews, the client has to search for the link with a rel "reviews" and follow it. This is pretty easy, as it doesn't need to know the URI structure.

Now, let's say there is a new business requirement and the reviews URI changes from /mystore/products/1/reviews to something like /reviewapp/reviews?product=1

Although the way the server is called has changed, the client is not affected as it will still be looking for the "reviews" link and following it.

Being aware of links in a resource, can be understood as part of the knowledge the client must have about the data. Thereby links become data and now the client has to deal only with data coupling, a problem that it already copes with. So, in some way, data coupling is helping to reduce communication coupling.

But this not only benefits the client, it also benefits the server, because it prevents the client from making incorrect calls.  The server prepares the call the way it needs to, reducing potential errors due to syntactically incorrect URI's or misuse of parameters.

It is a win-win situation because now the client doesn't need to worry about how to build the calls to the server and the server is receiving correct calls.

Conclusion

Reducing coupling is always something to go for it. It may be one of the oldest quests in software development. There are a lot of approaches in different scenarios and HATEOAS is one of them, specific for web applications in a Client-Server architecture.

The interesting part of HATEOAS is the benefits it provides for such a simple approach. Not only helps in reducing coupling but also provides the client a very easy mechanism that once adopted, any new resource published by the server, can be easily consumed, as it only needs to know which new link has to use. In addition, the reduction of erroneous server calls is significant, as long as the client uses the links, all the calls are correct, unless of course, the server built it incorrectly.  

In the next post, an approach on how to go further with HATEOAS and reducing filtering, sorting and paging coupling.