Re: [Jersey] What HATEOAS actually means

From: Paul Sandoz <Paul.Sandoz_at_Sun.COM>
Date: Mon, 15 Feb 2010 11:46:20 +0100

Hi Markus,

Thanks for getting involved in the discussion.

The following statement is in your blog wrong:

   There is only and exactly one valid implementation of HATEOAS:
Having links inside of the document.

The definition of an HTTP entity is as follows:

    Request and Response messages MAY transfer an entity if not
otherwise restricted by the request method or
    response status code. An entity consists of entity-header fields
and an entity-body, although some responses
    will only include the entity-headers.

Entity-header fields can consist link headers:

    A means of indicating the relationships between resources on the
    as well as indicating the type of those relationships, has been
    available for some time in HTML [W3C.REC-html401-19991224], and more
    recently in Atom [RFC4287]. These mechanisms, although conceptually
    similar, are separately specified. However, links between resources
    need not be format-specific; it can be useful to have typed links
    that are independent of their serialisation, especially when a
    resource has representations in multiple formats.
    To this end, this document defines a framework for typed links that
    isn't specific to a particular serialisation or application. It
    so by re-defining the link relation registry established by Atom to
    have a broader domain, and adding to it the relations that are
    defined by HTML.

The following are also pertinent to the general discussion:

Roy states at the end of his blog in the link above:

   The API can compensate for the use of POST by responding with the
statement that the client should refresh
   its representation of the larger resource state. In other words, I
would return a 303 response that redirected back
   to the VM status, so that the client would know that the state has

In the experimental prototype the client compensates by processing a
Link header of a link relation "refresh".

What we have been currently experimenting with is one particular
*pattern* of hypermedia [*], one that has also been investigated with
the API for the Sun Cloud (alas which IIRC may be no more).

We need to come with a number of patterns that can be applied to use-
cases and have corresponding prototype implementations and from all
that we will be able to hopefully define really good client and server
hypermedia API support!


[*] What ever you might think of it one thing it is not is RPC.

On Feb 14, 2010, at 4:32 PM, Markus Karg wrote:

> For those interested in the current hypermedia discussion, I'd like
> to point you to my latest blog entry about "What HATEOAS actually
> means". It might be interesting to follow its links into Fielding's
> dissertation so everybody understands what the recent discussion
> was / is about. It also explains why I think that the current Jersey
> proposal is invalid, since it is not implementing HATEOAS from the
> view of the dissertation but more from a pragmatic aspect of doing
> RPC via http.
> Regards
> Markus