The main points of

  • HATEOAS stands for Hypertext As The Engine Of Application State. In the Richardson Maturity Model, it is the highest form of REST
  • Single-page applications are becoming more and more popular. The development mode of separating the front and back ends further refines the division of labor, but also introduces a lot of repetitive work. For example, when some business rules must be implemented in the back end, the front end also needs to be implemented again to get a better user experience. HATEOAS is not the only way to eliminate these duplicates, but as an architectural principle, it makes it easier for teams to find “patterns” to eliminate duplicates

What is a HATOEAS

HATEOAS stands for Hypertext As The Engine Of Application State. Hypermedia’s API returns an additional set of links in response in addition to the resource itself. This set of links describes what the consumer can do next for the resource and what to do.

For example, if a GET request is made to the API to obtain representation of a given order, it should look something like this:

HTTP/1.1 200 OK Server: apache-coyote /1.1 Content-Type: Application/Hal +json; charset=UTF-8 Transfer-Encoding: chunked Date: Fri, 05 Jun 2015 02:54:57 GMT { "tracking_id": "123456", "status": "WAIT_PAYMENT", "items": [ { "name": "potato", "quantity": 1 } ], "_Links": { "self": { "href": "http://localhost:57900/orders/123456" }, "cancel": { "href": "http://localhost:57900/orders/123456" }, "payment": { "href": "http://localhost:57900/orders/123456/payments" } } }Copy the code
  • Consumers who understand “self” in Link know that using the get method to access the URI of their “href” can view the details of the order
  • Consumers who understand “cancel” in Link know that accessing the URI of their “href” using the delete method can cancel the order
  • Consumers who understand “payment” in Link know that using the POST method to access the URI of their “href” can pay for the order

REST is a pretty hot term in the industry right now, and it seems like you’re embarrassed to say hello to any API that doesn’t have a REST prefix. However, most apis that claim to be REST do not actually reach the third level of Richardson’s maturity model: Hypermedia. Dr. Roy Fielding, the inventor of REST, is even more outspoken that HATEOAS is the premise of REST, which is not an option, if there is no Hypermedia, it is not REST. (Excerpt from Infoq’s second interview with Dr Fielding)

So what advantages does HATOEAS bring?

One obvious benefit is that as long as the client always uses Link Rel to get the URI, the server can implement URI changes without breaking the client implementation, further decoupling the client and the server.

Another overlooked advantage is that it can help the client developers to explore API, the Links you can actually prompted developers for what kind of business operation, although developers proficient in technology, but often not understanding for the business, these tips can help them to understand the business, at least, is a good starting point to a query API documentation. Imagine an API with a new Link in its response. Sensitive developers might ask what the Link is for. Is it a new feature? While it may not seem like much, this often makes it easier for members of both teams to communicate.

Single page applications and HATEOAS

Over the past few years, there have been many major changes in WEB development technology, one of which is single-page applications, which tend to provide a smoother user experience. In this field, the division of labor is further refined. Front-end engineers specialize in client program construction and the development of HTML, CSS and other effects, while back-end engineers focus on high concurrency, DevOps and other skills. Most features need the cooperation of front-end and back-end engineers. One might wonder, why not a full stack engineer? Sure, if one person can deliver end-to-end features, it will naturally reduce communication costs, but full stack engineers are hard to find, and specialization is necessary to adapt to the scale development model. Following Ajax, single-page applications and the separation of the front-end and back-end architectures have further spawned a plethora of apis, and there is an urgent need for some way to manage the development and evolution of these apis, and HATEOAS should have a place in this space.

Move on and feel free to rename your resources

We often say that in agile development, you should embrace change. So techniques like refactoring, unit testing, and continuous integration are promoted in Agile development because they make change easier and safer. HATOEAS is one such technology. Imagine that at the beginning of a project, the team’s understanding of the business is not deep enough, and there is a good chance that the wrong business terms will be named, or that the business objects will not be modeled properly. Reflecting on the API, you might want to be able to fix the URIs of the API. In non-HatoEAS projects, since URIs are hard-coded on the client side, even if you design them beautifully (accurate HTTP verbs, plural named resources, no verbs, etc.), it won’t make it any easier to change them. Because your refactoring requires the front-end developer’s cooperation, he or she has to stop doing other work. But in projects with HATEOAS, this is easy because the client looks up the API’S URI via Link, so you can change its URI without breaking the API Scheme. Of course, you can’t guarantee that all API URIs are retrieved via Link. You need to arrange some Root Resource, such as/API /currentLoggedInUser, otherwise the client will not be able to make the first request.

HTTP/1.1 200 OK Path: / API /currentLoggedInser (1) {...... //omitted content "_Links": { (2) "searchUserStories": { "href": "http://localhost:8080/userStories/search{? page, size}" }, "searchUsers": { "href": "http://localhost:8080/users/search{? page, size, username}" }, "logout": { "href": "http://localhost:8080/logout" } } }Copy the code
  1. You can define multiple Root resources and ensure that their URIs do not change
  2. The URI introduced by Link is free to change, either because a resource needs to be renamed or because a new service needs to be extracted (domain name change)

Eliminating duplicate business rule validation implementations makes it easier to adapt to change

Experience tells us that client requests cannot be trusted, so on the server side we need to validate the current request against business rules. This ensures that the business is correct, but it can sometimes be frustrating to tell users that the request failed after they made it. For the sake of user experience, some components may be required to be presented according to business rules. For example, for a business object, the request edit button is displayed only if the current user can edit it. In the traditional server-side rendering architecture, checkable code can be reused in general, but in single-page applications, codes cannot be directly shared due to different technology stacks, and business rules are implemented at the front and back ends respectively. For example, in our most recent project, the front and back ends implemented the following rules:

  • Given a user story
  • Only its author can edit it

The server helps the front end do the conditional rendering of the edit button by exposing the author in the user story API.

HTTP/1.1 200 OK
Path: /api/userStories/123
{

​    "author": "[email protected]"  (1)

}
Copy the code

1. Determine whether to render the edit button by comparing it with the current user

However, if the rules change, both the front and back ends need to adapt to the change, so we used HATEOAS to reconstruct:

HTTP/1.1 200 OK Path: / API /userStories/123 {"author": "[email protected]", "_links": {"updateUserStory": {"href": "http://localhost:8080/api/userStories/123" (1) } } }Copy the code

2. Now the front end verifies that the current user has the ability to edit the user story based on the presence of updateUserStorylink

Later, the business rule became that in addition to the author, the system administrator could edit the user story, and only the back end was required to respond to the change. You may question, through to the user story exposed a isCurrentLoggedInUserAvailableToUpdate calculation attributes can too. Yes, HATOEAS isn’t the only way to do it, but as an architectural constraint, the team comes naturally to it, while computational attributes require more abstraction skills from team members.

conclusion

HATEOAS advocates returning a Link in response to indicate what to do with the resource next. This approach decouples the server URI and makes it easier for the client developer to explore the API. Finally, judging the business state by Link can effectively eliminate the repeated implementation of business rules in single-page applications.

For more insights, please follow our wechat official account: Sitvolk

WeChat
Sina Weibo
Evernote
Pocket
Instapaper
Email
LinkedIn
Pinterest