Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

In our What is REST? article we focused on a few of the important constraints of REST that are relevant to the SRP HTTP Framework. When discussing the Uniform Interface constraint, we provided an introduction to the concept of Hypermedia As The Engine Of Application State (or HATEOAS for short). In our summary of the concept of HATEOAS, we emphasized its importance but suggested the reader visit this present page to understand why HATEOAS is important.

Quick Answer

This Wikipedia article on HATEOAS nicely summarizes some key objectives and benefits of HATEOAS, so we will cite these here (the emphasis in the below citations are ours):

  • Since "...application servers provide information dynamically through hypermedia. A REST client needs little to no prior knowledge about how to interact with an application or server beyond a generic understanding of hypermedia."
  • "HATEOAS...decouples client and server enables the server functionality to evolve independently."
  • "All future actions the client may take are discovered within resource representations returned from the server."
  • "RESTful interaction is driven by hypermedia, rather than out-of-band information."

To be fair, there are plenty of people who appreciate REST in some respects, but ultimately do not see the significance or value of HATEOAS. This approach to RESTful APIs is often referred to as as pragmatic REST. RESTful APIs that emphasize HATEOAS is sometimes referred to as as purist REST (at times derisively by non-purist developers). This This article from Ben Morris represents  represents a well reasoned argument against the necessity of HATEOAS. He acknowledges the intent of HATEOAS , although we suggest that in some ways it indirectly advocates the need to engage HATEOASsuch as those listed above, but ultimately concludes that the cost of HATEOAS outweighs the tangible benefits. Our intent is not to debate the subject or pick apart any arguments against HATEOAS. Rather, we prefer to just outline our case for HATEOAS so each developer can make up their own mind. The important part is for a developer to decide early on whether or not HATEOAS will be a normal part of the API so this doesn't have to be shoehorned in or excised out later on in the life-cycle of API . This is why development. The facilitate developer choice, the SRP HTTP Framework does not enforce HATEOAS implementation but it does provide tools to implement HATEOAS relatively easy.

Digging Deeper

For those who want to a little m Perhaps some of the terminology used is It is important to define our terms and demonstrate our concepts in order to illustrate the importance of HATEOAS. We'll do this by looking at the core terms in the HATEOAS acronym: Hypermedia, Engine, and Application State.

Hypermedia

Hypermedia refers to content in a resource that is itself, or somehow it contains, a URI link to another resource. The most common type of hypermedia is we experience is hypertext. It is arguably the most significant reason why the web so easy to navigate and explore. Consider any website that you load into a browser. How does one discover and explore additional content that is available? We all know the answer: through the URI links available on the page. In HTML, we usually encounter these as text, or images, that are created using the anchor tag. Visitors do not require a road map nor do they need instructions on how to manually enter new URIs in order to access other content. The embedded hypermedia provides a visitor everything needed to continue. This addresses one important benefit of hypermedia: self-documenting systems. That is, assuming that the links are well labelled and clearly identified on the page, they serve as self-documenting elements that the users can easily understand.

...