One of my friends was recently asked this question in an interview. Even after searching on the web we couldn't come up with a suitable answer. Can anyone please explain what is HATEOAS and what's its purpose in REST architecture?
I'm definitely not an expert, so this might be a very limited and biased explanation, but it might help you get started with it.
One of the main benefit I see in Hateos is for self-describing APIs.
I'll start the explanation by summarizing how usual APIs are documented.
The common API are an endpoint, with some kind of signature, like /myendpoint/{arg1}/{arg2} or any form somewhat like this. Then to know what are the related datatypes and actions that can be performed from this endpoint, you need a documentation in some other place, make sure the API updates are correctly synchronized with the documentation, ...
Tools like Swagger does help. But although it's very helpful to correctly use a specific endpoint, there's little help regarding the logical flow of your APIs calls.
And that's where HATEOS comes handy. One goal of hateos is to provide a meaninfgul and standardized way to describe the action that can be done from the data you received.
In the end, you could have automated UIs that build themselves from the hateos informations, adding views and actions links to reflect the information returned.
Some colleagues did built such a proof of concept and it was really convincing.
You can see that the account-get action not only returns account information - which would be the usual answer in a traditional API - and the standardized link nodes gives you immediate information about the potential action and relevant other APIs to call. Without any other documentation you are already able to understand how the API - and not only this single endpoint - works.
As it's standardized and generated from your code, it can also be used in unit/integration automated tests.
This is only a very small explanation and, one more time, I'm not an expert. But I hope this could help you starting to get the point and motivates you enough to read more about it.
Hello
I'm definitely not an expert, so this might be a very limited and biased explanation, but it might help you get started with it.
One of the main benefit I see in Hateos is for self-describing APIs. I'll start the explanation by summarizing how usual APIs are documented. The common API are an endpoint, with some kind of signature, like
/myendpoint/{arg1}/{arg2}or any form somewhat like this. Then to know what are the related datatypes and actions that can be performed from this endpoint, you need a documentation in some other place, make sure the API updates are correctly synchronized with the documentation, ...Tools like Swagger does help. But although it's very helpful to correctly use a specific endpoint, there's little help regarding the logical flow of your APIs calls.
And that's where HATEOS comes handy. One goal of hateos is to provide a meaninfgul and standardized way to describe the action that can be done from the data you received.
In the end, you could have automated UIs that build themselves from the hateos informations, adding views and actions links to reflect the information returned.
Some colleagues did built such a proof of concept and it was really convincing.
Since a concrete example might be helpful, you can have a look at this REST Cookbook sample: What is HATEOAS and why is it important for my REST API?
You can see that the account-get action not only returns account information - which would be the usual answer in a traditional API - and the standardized link nodes gives you immediate information about the potential action and relevant other APIs to call. Without any other documentation you are already able to understand how the API - and not only this single endpoint - works.
As it's standardized and generated from your code, it can also be used in unit/integration automated tests.
This is only a very small explanation and, one more time, I'm not an expert. But I hope this could help you starting to get the point and motivates you enough to read more about it.