BT

HATEOAS as an engine for domain specific protocol-description

by Dilip Krishnan on Jun 04, 2009 |

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?

Hello stranger!

You need to Register an InfoQ account or or login to post comments. But there's so much more behind being registered.

Get the most out of the InfoQ experience.

Tell us what you think

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

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.

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

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.

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

3 Discuss

Educational Content

General Feedback
Bugs
Advertising
Editorial
InfoQ.com and all content copyright © 2006-2014 C4Media Inc. InfoQ.com hosted at Contegix, the best ISP we've ever worked with.
Privacy policy
BT