Facilitating the Spread of Knowledge and Innovation in Professional Software Development

Write for InfoQ


Choose your language

InfoQ Homepage News HATEOAS as an engine for domain specific protocol-description

HATEOAS as an engine for domain specific protocol-description

This item in japanese


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?

Rate this Article


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.

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

Community comments

  • A Better Description?

    by Ryan Riley,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    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,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    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,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    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

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