Of the four interface constraints underlying the REST architecture, the constraint that "hypermedia as the engine of application state" is cause for some confusion. As Stu Charlton once noted, it is also the most often ignored constraint in reality. While this constraint does some offer some benefits, I do see practical reasons why this constraint is ignored, particularly for non-userfacing applications, and there are benefits to ignoring it.
In his thesis, Roy Fielding describes four interface constraints for REST. These are (a) identification of resources through URIs, (b) manipulation of resources through their representations, (c) self-descriptive representations, and (d) hypermedia as the engine of application state.
What does this constraint mean? Referring back to Roy’s thesis,
Distributed hypermedia provides a uniform means of accessing services through the embedding of action controls within the presentation of information retrieved from remote sites.
The rationale behind this fourth constraint is that, by embedding actions controls and URIs within each representation, the client remains independent of the server, and therefore can be universal. The representation that the client receives would include possible new state changes, the URIs and methods that could be used for those transitions, and any associated ordering semantics. As John Heintz recently noted, embedding action controls with each representation yields the following benefits.
- The client doesn’t need to have generated (and hard-coded) client stubs
- The server can change it’s rules and expand available states as needed
- The client does need to process a generically extensible content type
In essence, since the representation will be self-contained, the fourth constraint takes away the need for a shared understanding of any ordering rules between interactions. The shared understanding is embedded within the representation and the client does not have to know it a priori. All the benefits that John points out can be realized with a generic and universal client that can understand a particular set of media-types. For example, a web browser understanding HTML can work within the fourth constraint since it is programmed to understand and interpret the embedded action controls and the algorithms to construct URIs without any server-specific pre-programming. To quote Stu again,
All a consumer requires is a single URI to bootstrap the interaction process.
True. This is the reason why web browsers have become de-facto application clients.
Should this idea be extended to the rest of non-user facing resource-oriented applications? I don’t think so. Here is why.
The idea of hypermedia embedding all the action controls necessary to interact with the server works well for an arbitrary number of universal clients interacting with a given server. In this case, the server offering a set of resources specifies all the ordering/interaction rules within the representation. Most application clients, on the other hand, interact with more than one server, and the ordering constraints can not be set by any given server. The clients know how to compose applications out of resources offered by various servers, and each client needs to be able to exercise control over composition. To be able to exercise such a control, client applications can not be universal, and the benefits that John lists above cannot be completely realized. And that is why, IMHO, the fourth constraint about hypermedia is often ignored.