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.
Our June 2013 update for the Apigee API Platform delivers a number of new features including the ability to easily build a REST endpoint for a SOAP back-end service. The wizard based approach makes it easy to model your SOAP API as REST, with meaningful resource names and verbs generated from the SOAP operations.
Check out this short video for a summary.
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.