Trisha Shetty (Editor)

HATEOAS

Updated on
Edit
Like
Comment
Share on FacebookTweet on TwitterShare on LinkedInShare on Reddit

HATEOAS, an abbreviation for Hypermedia As The Engine Of Application State, is a constraint of the REST application architecture that distinguishes it from most other network application architectures. The principle is that a client interacts with a network application entirely through hypermedia provided dynamically by application servers. A REST client needs no prior knowledge about how to interact with any particular application or server beyond a generic understanding of hypermedia. By contrast, in some service-oriented architectures (SOA), clients and servers interact through a fixed interface shared through documentation or an interface description language (IDL).

Contents

The HATEOAS constraint decouples client and server in a way that allows the server functionality to evolve independently.

Details

A REST client enters a REST application through a simple fixed URL. All future actions the client may take are discovered within resource representations returned from the server. The media types used for these representations, and the link relations they may contain, are standardized. The client transitions through application states by selecting from the links within a representation or by manipulating the representation in other ways afforded by its media type. In this way, RESTful interaction is driven by hypermedia, rather than out-of-band information.

For example, here is a GET request to fetch an Account resource, requesting details in an XML representation:

Here is the response:

Note the response contains 4 possible follow-up links - to make a deposit, a withdrawal, a transfer or to close the account.

Some time later the account information is retrieved again, but now the account is overdrawn:

Now only one link is available: to deposit more money. In its current state, the other links are not available. Hence the term Engine of Application State. What actions are possible vary as the state of the resource varies.

A client does not need to understand every media type and communication mechanism offered by the server. The ability to understand new media types can be acquired at run-time through "code-on-demand" provided to the client by the server.

Origins

The HATEOAS constraint is an essential part of the "uniform interface" feature of REST, as defined in Roy Fielding's doctoral dissertation. Fielding has further described the concept on his blog.

The purpose of some of the strictness of this and other REST constraints, Fielding explains, is "software design on the scale of decades: every detail is intended to promote software longevity and independent evolution. Many of the constraints are directly opposed to short-term efficiency. Unfortunately, people are fairly good at short-term design, and usually awful at long-term design".

Implementations

  • Spring HATEOAS, part of the Spring Framework
  • Yii 2 Framework REST API supports HATEOAS, part of the Yii Framework (since version 2.0)
  • Jersey API supports HATEOAS
  • Tastypie supports HATEOAS
  • Eve supports HATEOAS
  • Apigility, API builder based on Zend Framework 2, supports HATEOAS
  • Hateoas PHP library, supports HATEOAS REST Web Services implementations.
  • API Platform, PHP framework based on hypermedia and Linked Data support with JSON-LD, Schema.org and Hydra
  • AtomGraph Processor, a Java backend for building declarative, read-write Linked Data applications, supports HATEOAS Linked Data
  • References

    HATEOAS Wikipedia