HATEOAS Design Principle. Giving Power To Your Application Backend!!!
You would be wondering what I mean by giving power to your application backend. So just to give you a brief, HATEOAS gives the server/backend the power to control the flow of your application completely by letting the client have little to no knowledge of what to do next until the server guides it.
Anyone who has worked with REST APIs as well as the client-server model and had made their hands dirty by actually implementing such applications, they would have already got an idea of what power I am talking about.
If not, don’t worry before the article ends you would come to know what kind of power I am talking about.
Note: In this entire article wherever I have used client it means a frontend side and wherever I have used server it means backend side of the application
Introduction
Before moving further with HATEOAS its good to have a brief about REST.
What is REST (Representational State Transfer)?
It’s an architectural style that lays down some standards which need to be followed while creation of Web Services. The Web Services that follow REST provides interoperability between different systems over the internet.
The best example of RESTful APIs are web services working with JSON objects. As JSON objects are cross-platform due to which the same web service can be used on a mobile platform as well as web browsers.
Now starting with HATEOAS design principle:
HATEOAS stands for Hypermedia As The Engine Of Application State. It is a part of REST application architecture and is a constraint for REST.
Here Hypermedia refers to any content that contains links to other forms of media such as video, audio, image, and text.
This design principle states that when the client interacts with the server, the server provides information dynamically in the form of hypermedia. Due to this client should have very little to no knowledge about how to interact with the server. Here we used a phrase little knowledge because the client should know regarding how to deal with hypermedia.
Actually in this, if we think from the application state and flow perspective everything depends on the server, like what action should be available to the client after a particular action/API is performed by the client.
The client does not know what are the actions that would be available after a particular action is performed and so the client itself will work with little to no business/application knowledge on their side.
Now you must have understood the meaning HATEOAS design principle which in short states that using hypermedia we can control the state of the application and so hypermedia is referred to as an Engine Of Application State.
After such a long explanation now let’s jump on to an example to get a better understanding of whatever we read above
For example, there is a REST API that gives information about the bank account detail of a user and the response of the API is in JSON format as shown below:
So here as you can see with other pieces of information regarding the account details like account_number, balance, there is a set of links provided.
These are the links that are the available actions for the client to perform after the action of fetching the account detail is performed.
Here if you noticed based on the REST API response client can decide which next actions can be performed. Due to this client doesn’t need to know about any other actions of the system beforehand.
After having available actions, for example, the user (that is using the client to access the server) decides to proceed with withdraw action and the user withdraws USD 125.
The response from the withdraw API is shown below:
So here now the total amount (value) in the bank account is negative and due to which only one action is available for the user, which is depositing the money in the bank account.
All other actions that were previously available are no longer available due to the business requirement, that is if the total amount in the bank account of the user is negative he/she cannot: withdraw, transfer or close the account.
Here you can see that clients don’t need to maintain any flow or logic such as if the amount is negative then don’t show the other options except deposit.
All this is taken care of by the server at runtime and the client is provided with this information/state of the application on runtime by the hypermedia (hyperlink + other data) provided in the response of the previously performed action by the client. That’s why we call it as Engine Of Application State.
Final Words
This way we can completely make the client-side dynamic, which act according to the responses of the REST APIs(actions) previously performed by the client and so the client do not require more knowledge of how to interact with the server beforehand.
Here just to make one thing clear, the client would be having an initial/base URL API endpoint for the server, and then from there it would be dynamically changing the state of the application depending on the links available in the response of the action performed.
So hyperlink changes the application state and it is not the other way around.
Using HATEOAS, REST client (or simply client) don’t have to hardcode the URL structures of the application resources beforehand.
This also decouples the client and the server in the sense if the server needs to change/evolve the URL of any of its resources it can easily do without having any changes needed to be done on the client end. Because now it would not be hardcoded and this is how HATEOAS decouples client and server which in turn enables server functionality to evolve independently.
Thanks for reading the article!!!
