HATEOAS or Hypermedia As The Engine of Application State is a component of REST Application Architecture. Roy Fielding, who is the creator of REST Architecture also laid down the HATEOAS framework. HATEOAS is a bit of a tricky topic because of its inherent need as well as its complicated implementation. In this article, we will try our best to explain what is HATEOAS, The Benefits, and The Drawbacks. But to get a better understanding we need to first understand what is Hypermedia.
What is Hypermedia?
The most basic definition of Hypermedia for the uninitiated may be described as a system in which various forms of online information, such as text, data, videos, graphics, and audios, are linked together by a hypertext program. A common misconception is considering Hypertext as Hypermedia. Although the two are closely related, as the bulk of webpages are primarily written in HTML (Hypertext Markup Language), Hypermedia is so much more. Hypermedia not only relates to text but it can also mean videos, graphics, animated GIFs, music, etc.
What we generally call these days “interactive multimedia” is, in essence, a newer name of the same thing. The contemporary use of the term Hypermedia or interactive media is usually in the context of Web-Based API development. When your browser loads a certain webpage with all its contents, apart from seeing all the information on your display, you also get to perform certain actions by clicking or typing.
A Simple Request With HATEOAS
Once your webpage loads, let say you send a command to retrieve specific details from your resource. Through a simple GET request to a RESTful Server, your data will be displayed. Usually, while performing a REST request, the only thing we get is data. But what if you want to do some actions around that data or service? This is where HATEOAS shows up as our knight in shining armour. A HATEOAS request allows the requester to not only send the data but also enables to specify the actions. Simply put with the help of HATEOAS, A REST request not only gives the developer data but it also enables the developer to perform certain actions related to that data.
Using HATEOAS allows an API to clearly define a control logic that is available at the client-side. This enables them to follow links embedded in the API resources instead of having them manipulate URLs. This decouples clients from the URL structure so that changes don’t end up hurting integration.
Does HATEOAS Really Matter?
HATEOAS is one of the elements that add to the difficulty level of RESTful Architecture. Do all of today’s RESTful integrations use HATEOAS? The simple answer is no. But when the service providers change their internal processes and URLs usually these integrations break. All those hardcoded implementations break because there is not a standardized way for them to relocate their resources. This is just one of the main reasons why HATEOAS is followed.
HATEOAS is not only easier to version, but it also helps ease migration for older client applications and makes backward compatibility also less of a chore. On the client-side, only the API’s base URI is needed to discover all resources. For the client through a HATEOAS compliant API, all the information is directly delivered from the server-side to the client. A Rest Client needs no prior knowledge about how to interact with it besides a general understanding of hypermedia. However, one might interpret it, the fact remains HATEOAS is not easily implemented. Sometimes the drawbacks will drown out the benefits received from using HATEOAS. This all depends on the developer and what the company wants to achieve.
Benefits of HATEOAS:
Below are some of the benefits that can be achieved by using HATEOAS:
- Reduced Coding Errors – Client Side
Due to a strict focus on the usage of URIs (i.e. Unique Resource Identifiers), about 90% of bugs can be removed using HATEOAS. Typically, mistakes are made by leaving out path segments, putting them in the wrong order. Sometimes even coders forget to URL encode things. These common human errors can be minimized using a HATEOAS approach.
- Mitigation of Invalid State Transition calls
It is not allowed to start a virtual machine until it has been deployed. The server only initiates the state changes via a “POST” request, the representation of Virtual Machine only lists the URIs for state transitions that are valid from the current state.
- Detailed Application Upgradation Without Client Breakage
Clients of a REST API are usually programmed with certain assumptions in regards to how the system works and what are its limitations. APIs can be evolved fairly quickly if the developer properly documents a restriction to pay attention to and specifically targeting certain aspects of the system. This along with a solid server-side logic for the addition of things at a later stage. A strong developer can also ensure all this doesn’t disrupt previously coded behaviors. Through this approach, APIs can be evolved fairly quickly.
This also ensures that all the clients stay in working condition. It also helps to reduce the developer’s workload, by avoiding multiple versions of an API on the server. This might arguably be one of the key benefits of implementing HATEOAS compliant APIs.
Disadvantages of HATEOAS:
All of this might seem good but as is with life there are a few things that aren’t so great about HATEOAS. Let’s take some time to look at the other side as well.
- Harder to Implement
While getting URLs might seem convenient from the client-side. Generating these URLs, unfortunately, falls back on the backend programmer. This inadvertently makes it much more complicated for the backend programmer, making it much harder to write the API’s backend. This makes the implementation of HATEOAS a lot harder.
- Resource Hungry Architecture
To some, this might seem trivial, but including all those URLs in the response and also storing them on the client-side puts a lot of load on the network and memory usage. Although the network might not end up being the major concern/issue due to data compression (unless there is an enormous number of Items). Memory usage is, however, does become a huge concern. Large chunks of data processing definitely takes a huge toll on the system. It will be therefore much more convenient to just concatenate a predefined template and UID to get a URL, rather than searching through hundreds (if not thousands) of records to find just one.
- Reduced Flexibility
In certain cases, allowing the client to generate its own URLs results in constricting the system. Especially in cases where the client’s responses are much more volatile and unpredictable. Since everything that can be done is already predefined through the server, the client has very little options to operate freely.
- Small Applications Suffer
While large applications might still find certain uses of HATEOAS, smaller applications do end up suffering. For an application with a very limited user base and a single client, there is no point in adding the overhead of HATEOAS. Smaller applications can be easily updated as per your requirements.
- Information Overload
With HATEOAS compliant API, clients usually end up with a lot more information than what is required. This additional information is useless and probably will never even be looked at. While this might not necessarily be a big issue it is an unnecessary byproduct of HATEOAS.
Final Thoughts
There is no doubt that HATEOAS is strict in its regulations and even tougher in its implementation. What this means is a lot of overhead during development, implementation, and execution. If you truly want your API to be RESTful than you will have to become HATEOAS compliant. This can be useful if you have a high userbase with an ever-changing need for API up-gradation, while also having a high amount of resources at your disposal.
However, HATEOAS compliance is really not necessary for a good API Integration. There are other options out there also and some might argue those to be much better. It all depends on your business needs and strategy. The best approach would hence be to do your research beforehand or hire API Experts that can help you decide your next big step.
We at Help Square specialize in analyzing your business needs and providing the best solutions. From the planning phase to development, beta testing and implementation phases we do it all. Just reach out to us to find out more.
