A lot has been written about the Hypermedia Constraint, a.k.a. HATEOAS. I’ll avoid the acronym because… well, because it’s a horrible acronym. I’ll follow Roy Fielding’s example and call it the Hypermedia Constraint.
Following Dr. Fielding’s famous rant, REST API pundits and practitioners have done a lot of soul-searching, and engaged in heated debate, trying to decide exactly what the Hypermedia Constraint entails, what a conformant API is supposed to look like, and whether it makes sense to adhere to this API design style in mainstream web services, SOA, and microservice architectures.
What does it mean to be hypertext-driven? I studied this in some detail, trolling through the comments, reading Fielding’s subsequent discussions with the SocialSite developers, piecing this together with the REST thesis, and with related threads in REST-discuss and API-Craft. I’ve never studied the Talmud, but I think this might be a similar experience.
What comes to light is that hyperlinks, media types and link relations play several different roles in a fully realized REST architecture. RESTful use of hypermedia accomplishes several goals:
- Separates concerns between between the client and server.
- Defines a processing model that drives application state.
- Specifies message syntax and semantics as a data contract.
I believe a lot of the confusion and controversy stems from the simple fact that these aspects of hypermedia — encapsulation, processing model and data model — are three different things, and the debate has taken place about all three aspects simultaneously. Some arguments focus on one or two aspects only, and extrapolate these as general endorsements or indictments of Fielding’s position, or of hypermedia, or even of REST overall. Others seem to attempt a general point about hypermedia, without being clear as to which aspect is being addressed.
So I think it’s useful to separate and describe these architectural aspects, so we can understand what it means to be hypertext-driven. My next several posts will drill into each of these aspects, and place them in the broader context of REST interface design. Stay tuned…
Read the next post in this series:
Hypermedia Part 2: Couples Therapy for API Providers and Consumers
Submit the trial registration form.
Check your inbox for download instructions.
Download and run the automated installer.
