In our last post, we talked about pure REST and HATEOAS. In this post, we'll propose some ideas to initiate the creation of a new API design model based on pragmatic REST. We need to create an intellectual framework for API design that captures the spirit of how most popular web APIs are designed today.
In Part 1 of this discussion, we looked at questions people have in regard to HATEOAS. Now let’s examine how API crafters can revise their API so that it is truly RESTful. Because this is an introduction, we’ll avoid going into detail. Instead, we’ll assert the key point upfront: pure REST APIs require hypermedia clients.
Previously, we discussed HATEOAS (the hypermedia constraint) within the context of REST. This laid the groundwork for our discussion today, which is how to apply HATEOAS to an API strategy. Now, let’s look at some questions people have in regard to HATEOAS when setting up their API.
We recently discussed the six constraints of REST but today we'll deepen our discussion of hypermedia as the engine of application state or HATEOAS (hay-dee-ous), in an attempt to understand what HATEOAS really means.
Over the next several blog posts, we’d like to discover what hypermedia as the engine of application state, or HATEOAS (“Hay-dee-us”), means. We'll start by considering each of the six constraints of the architectural style of REST as defined by Roy Fielding in his PhD dissertation, with an emphasis on HATEOAS.
Previously, we explored how to represent actions and metadata in response messages, specifically state transitions that come from a particular resource. Now, we'd like to discuss hypermedia APIs, one of the keys to offering resource representations rich with information and controls, such that information becomes the conduit by which the user obtains choices and selects actions.