"Real" HATEOAS support for JAX-RS

From: Markus Karg <>
Date: Mon, 15 Feb 2010 19:56:44 +0100

Building on Fielding's (and only Fielding's) actualy words in his blog and
dissertation (what lead to my blog entry yesterday) I'd like to propose a
different API for hypermedia support:


Fielding wants RESTful applications to have state information found inside
of the document (see, so
the question is, how this can be supported by JAX-RS?


On the server side, there must be something (let's call it
"MessageBodyEnricher") that is able to modify URIs INSIDE of entities. Just
as JAX-RS already supports CREATION of entities from Java objects by an
extensible framework (MessageBodyWriter), there needs to be an extensible
framework for ENRICHMENT of entities with a supplied list of links
("MessageBodyEnricher"). I could imagine that MessageBodyWriter just gets an
additional set of methods for adding URIs valid in the current state. The
MessageBodyWrite would then process the links by adding it into the binary
result. Example: If the result is HTML, the enrichment would be adding a
list of <a>. That is exactly the example fielding gave in his dissertation.
As more typical message bodies are e. g. XML, the enrichment must happen by
adding XLinks at time of message body writing.


On the client side, there must be just NOTHING as the client typically is
able to parse and understand the received content. Example: If the result is
HTML and the client is a browser, it will understand the contained list of
<a> and the user selects one and clicks it. A more typical message body will
be e. g. XML, so the client software will understand the XML schema's
semantics and pick the right XLink from it, on discretion of the workflow it
wants to drive.


This is a 1:1 translation of what the dissertation and Fielding's above blog
entry tells us, it is 100% HATEOAS and REST, it is independent of the
protocol. But it might be not what you like to get or like to do?