Page History
...
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 pragmatic REST. RESTful APIs that emphasize HATEOAS is sometimes referred to as purist REST (at times derisively by non-purist developers). This article from Ben Morris represents a well reasoned argument against the necessity of HATEOAS. He acknowledges the intent of HATEOAS such 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 to avoid shoehorning it in or excising it out later on in the life-cycle of API development. To 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 HATEOASIt might help to explore some of these concepts a little more. 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.
...
These two benefits can also apply to web APIs. If our resource objects contain hypermedia, then our APIs become self-documenting. If the system that communicates with our API understands that it will receive hypermedia then we will achieve client/server independence. Our APIs, then, can evolve much easier (as well as the client relying on our APIs). This Martin Nally article doesn't discuss REST or HATEOAS directly, but it does provide a very thoughtful and compelling reason for using hypermedia (aka links) in APIs.
Engine
In this context, engine is an abstract term meaning the force that produces a result. By itself it doesn't mean anything but it does connect the force (hypermedia) with the result (application state).
Application State
For our purposes, application state refers to the resource content as it exists in the client at a specific point in time. As we have noted above when describing hypermedia, web servers (and web APIs) return digital content, but this content can be separated into two categories: static and hypermedia. Static data is what a client considers meaningful and directly related to the URI itself (e.g., GET /orders/1234 is expected to return information related to order #1234, such as customer number, order date date, line item detail, etc.). Hypermedia data, however, informs the client what new states are available. For instance, our order resource might also include the following hypermedia:
...
