HATEOAS as an engine for domain specific protocol-description

Posted by Dilip Krishnan on Jun 04, 2009

Sections

Architecture & Design,

Enterprise Architecture

Topics

WOA ,

REST ,

SOA

Tags

WS-BPEL ,

WADL ,

HATEOAS

Explaining HATEOAS is notoriously tricky, In an effort to make it easier, Nick Gall explores the idea of describing it as an engine for domain specific protocol-description. Traditionally According to him HATEOAS is described by

... highlighting that HATEOAS requires that each server response must contain not only the requested data — but also control information (in the forms of specially tagged URLs) describing the next set of permitted interactions with the server. It is this additional control information (at a bare minimum just some links to more data) that turns mere media into hypermedia.

Nick explained how he views web interfaces (and consequently RESTful interfaces) in terms of Identifiers (Uri), Formats (HTML), and Protocols (HTTP) (IF and P). According to him, though its true that RESTful applications using HATEOAS can be thought of as the sum of the three components (IF and P). Thinking of hypermedia as a domain specific protocol description might be more appropriate when it comes to understanding it. He points to Jim Webber’s “Restbucks” example/presentation in which he describes using hypermedia for protocol description.

At first this might seem counterintuitive, since I said that HTTP is the Protocol and HTML is the Format in the WWW. But URLs, HTML, and HTTP are just generic description languages for describing domain-specific identifiers, formats, and protocols. Thus, think of a web of specific HTML pages as a domain-specific protocol.

The comparison this idea of “Hypermedia describes Protocols” to the WS-BPEL 1.1 spec or WADL is inevitable. He says 

The fundamental difference is that WS-BPEL is based on the concept of providing an entire static protocol description up front once and for all — and providing it out of band. But HATEOAS is based on the notion of progressive description I guess another good term might be JIT Protocol Description (Just In Time). […] I can say "each server response progressively self-describes the current protocol."

The just-in-time protocol description has its advantages and disadvantages over upfront descriptions and they lie in the tooling support and discoverability of these interfaces. Is “Hypermedia describes Protocols” the new way to think about the notion of HATEOAS, and does it make it easier to understand?

1. Back to top

   A Better Description?

   by Ryan Riley

   I'm not sure that "Hypermedia describes Protocols" is a much better term. Now you just introduce potential confusion on the definiton of protocols instead of state. "Hypermedia Just-in-time Workflows" or "Hypermedia State Machines" would probably be a better description.

   Reply

2. Back to top

   HATEOAS is architectural style concept

   by Lee Wayne

   Note that HATEOAS belongs to architectural style domain as REST. To me, domain specific architecture will definitely require some out-of-band info / prior knowledge / domain know-how to work, where HATEOAS/REST may fit in or not.
   
   BTW: slides I wrote myself to explain Why HATEOAS

   Reply

3. Back to top

   Horrible acronymn

   by Steve Macdonald

   HATEOAS remains one of the most awkward and ugly acronyms in any technical field. No wonder the concept behind it has trouble getting traction.

   Reply

• Older >