RE: [Jersey] What HATEOAS actually means

From: <>
Date: Mon, 15 Feb 2010 15:30:55 -0600

I agree with everything here except the last sentence. I do agree it is
not needed since I currently do it myself in application code.... So I
know from that experience that it is pretty painful and I would definitely
support and appreciate some kind of framework support to make this a LOT
easier to implement!


"Markus Karg" <>
02/15/2010 03:25 PM
Please respond to


RE: [Jersey] What HATEOAS actually means

I did never say that Jersey shall be protocol independent or that there is
a protocol independent framework. I said that REST is a protocol
independent idea and the dissertation / Mr Fielding's blog says that links
must be in the document since otherwise it would not be REST or it would
not work to send the same document with a different protocol and get the
same links.
See, RESTful *any* client must be able to use *any* RESTful server. Just
as *any* browser can view *any* web site. If your bank account web site
would only work if your browser understands special headers, you would
never be able to see your balance. THAT is what is meant with "protocol
independent": If you transfer the links in the headers, only *YOUR* client
would be able to process them -- even if a different client perfectly
understands your MIME type and could find links embedded in there, it will
have no chance to understand your link list since it does not understand
you headers. Got it? Don't write clients that work only with *your*
servers, and don't write servers that will only work with *your* clients.
Any browser works with any server, so the complete discussion in the
Jersey newsgroup is useless, as we do not want to get Jersey clients that
only work with Jersey servers and vice versa, but we must provide a server
framework that provides a media stream that *any other* client will
understand, and we must provide a client framework that will understand
the media stream sent by *any other* server. Got it now? :-)
Yes, it is not REST if you provide the links in the header. Check the
dissertation, and check the blog entry of Fielding Do
it. It is not me THINKING that, it is Fielding DEFING so. It is not MY
point. It is HIS.
And, as I said several times, YES frameworks CAN support HATEAOS, but NO I
do not see a need for that. That's why I write: "It is useless".
From: Santiago.Pericasgeertsen_at_Sun.COM
Sent: Montag, 15. Februar 2010 21:18
Subject: Re: [Jersey] What HATEOAS actually means
 I think this notion of using HTTP is going off a tangent. There is no
such thing as protocol-independent framework (like Jersey). Frameworks can
only implement a finite set of protocols. Architectures like REST can be
protocol independent, but frameworks need to provide a binding from
architectural concepts to real protocols, such as HTTP.
 JAX-RS defines such a binding and makes use of HTTP headers like Accept,
Content-Type, etc. Does that mean it's not REST?
 I understand your point about hyperlinks in documents, it's an
interesting point IMO. Rather than focusing on the binding, I think it's
more interesting to discuss if frameworks can help with HATEOAS. What is
your take on that? Do you think there's any need for it?
-- Santiago
On Feb 15, 2010, at 1:41 PM, Markus Karg wrote:

sorry but I have to insist on what I wrote on my blog:
"There is only and exactly one valid implementation of HATEOAS: Having
links inside of the document."
Why? First of all, because it is exactly written in both, Fielding's
dissertation Chapter 5.2, and nine years later in that blog
entry he wrote. If you don't believe me, just ask him (nothing else I want
to reach: stop guessing and discussing, just ask the RESTmaster himself!).
Second, because REST is an abstract pattern, just as HATEOAS is. It is
unrelated to http. According to Fielding, it must be possible to use do
the same RESTful application on different protocols without modifying the
document. If you send state information outside of the document, e. g. in
the headers, then this will not work when using a protocol that has no
such thing like headers.
HATEOAS is not about sending state information anywhere, it is about
sending stahte information in the MEDIA. But headers are not media, only
the document is. It is true that http allows to send information in
headers (never said something against that), but that is not part of the
MEDIA. And after all, the H in HATEOAS is from "HyperMEDIA" not from
Also I never said that http forbids to send links in headers. This is
valid http. But it is neither HATEOAS nor REST.
From: Paul.Sandoz_at_Sun.COM [mailto:Paul.Sandoz_at_Sun.COM]
Sent: Montag, 15. Februar 2010 11:46
Subject: Re: [Jersey] What HATEOAS actually means
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 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:
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
[*] 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.

Please consider the environment before printing this email and any

This e-mail and any attachments are intended only for the
individual or company to which it is addressed and may contain
information which is privileged, confidential and prohibited from
disclosure or unauthorized use under applicable law. If you are
not the intended recipient of this e-mail, you are hereby notified
that any use, dissemination, or copying of this e-mail or the
information contained in this e-mail is strictly prohibited by the
sender. If you have received this transmission in error, please
return the material received to the sender and delete all copies
from your system.