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:
http://greenbytes.de/tech/webdav/rfc2616.html#entity
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:
http://tools.ietf.org/html/draft-nottingham-http-link-header-07#section-1
A means of indicating the relationships between resources on the
Web,
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
does
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:
http://www.tbray.org/ongoing/When/200x/2009/03/20/Rest-Casuistry
http://roy.gbiv.com/untangled/2009/it-is-okay-to-use-post
http://www.dehora.net/journal/2009/02/03/just-use-post/
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
changed.
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!
Paul.
[*] 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.
>
> http://weblogs.java.net/blog/mkarg/archive/2010/02/14/what-hateoas-actually-means
>
> Regards
> Markus