REST HATEOAS - How does the client know the semantics of links?

Imagine that I have a fully implemented REST API that also offers HATEOAS.

Suppose I look at the root directory and, in addition to the kernel link, two other links are returned (for example, one for /users and one for /orders ). As far as I heard, HATEOAS eliminates the need for out-of-band information. How should a customer know what users mean? Where are semantics stored?

I know this is a stupid question, but I really would like to know that.

+6
source share
2 answers

Suppose you just discovered Twitter and are using it for the first time. In your web browser, you see a paragraph column with a bunch of links spreading across the page. You know that there is a way to do something with this, but you don’t know specifically what actions are available. How do you find out what it is?

Well, you look at the links and think about what their names mean. Some of them are immediately recognized by convention . As an experienced web user, you have a pretty good idea that to achieve this you need to click on the links "home", "search" and "exit".

But other links have names that you don’t recognize. What does retweeting do? What does the icon of this little star do?

Basically you can or not:

  • Through the experiment , that is, clicking on the links and viewing what is happening, then deriving the meaning for each link from the results.

  • Through some source of out-of-band information , such as online help, a tutorial found through a Google search, or a friend sitting next to you, explaining how the site works.

Same thing with the REST API. (Recall that REST is designed to model how the Web interacts with people.)

Although, in principle, computers (or API client developers) could derive the semantics of relationship relationships through experimentation, this is obviously not practical. It leaves

There is nothing controversial in the concept of REST, requiring client developers to rely on something other than the API itself to understand the meaning of link relationships. This is standard practice for people using websites, and people using websites are REST models.

What REST does is eliminate the need for out-of-band mechanism information API interactions. Returning to the Twitter example, you probably should have someday explained to someone exactly what is going on in the retweet link. But you didn’t need to know which specific URL you entered to retweet, or the tweet ID you wanted to act on, or even the fact that the tweets had unique identifiers. Web design meant that all this complexity was taken care of by you as soon as you figured out which link you would like to click.

And so it is with the REST API. It is true that in most cases, the computer or programmer just needs to say what the relation of each link means. But once they get this information, they can navigate throughout the API without having to know anything else about the details of how it all comes together.

+12
source

REST does not eliminate the need for out-of-band information. You still need to document your media types. REST eliminates the need for out-of-band information when the client interacts with the underlying API protocol.

Semantics are documented by the media type. Your root API is a media type resource, say something like application/vnd.mycompany.dashboard.v1+json , and the documentation for this type of media explains that the link users relationship leads to the application/vnd.mycompany.user.v1+json associated with the authenticated user and orders leads to the set application/vnd.mycompany.order.v1+json .

The library is similar here. When you enter the library after the book, you know how to read the book, you know how to go to the bookshelf and pick up the book, and you know how to ask the librarian about directions. Each library can have a different structure, and bookshelves can be organized in different ways, but as long as you know what you are looking for, and you and the librarian speak the same language, you can find it. However, it is too much to expect a librarian to teach you what a book is.

+1
source

Source: https://habr.com/ru/post/971977/


All Articles