Paul,
agreed. Actually I didn't move the posts but changed the team, after
learning about the "Link" header from Mr Fielding. ;-)
-Markus
From: Paul.Sandoz_at_Sun.COM [mailto:Paul.Sandoz_at_Sun.COM]
Sent: Dienstag, 16. Februar 2010 21:14
To: users_at_jersey.dev.java.net
Subject: Re: [Jersey] What HATEOAS actually means
Hi Markus,
IMHO you are "moving the goal posts" :-)
However, i think we understand each other now and i have no interest in
discussing the matter further.
Paul.
On Feb 16, 2010, at 6:45 PM, Markus Karg wrote:
Yes, as I just have read (had to stop working yesterday) the RESTmaster
enlighted me that *some* headers are indeed valid. The problem is two
things: (a) The Link header is not yet part of the http standard, so
"officially not existing". A foreign client would not expect to check any
"officially not existing" header, so it would be incompatible with the
proposed solution. (b) Content-Location is only valid, as he explained, for
the URI of THIS content, so cannot be used for anything else, same for
Location which is only valid for redirections. That means, foreign clients
will never check those headers. So yes, it is valid to have links in that
headers, but it will lead to incompatible clients. And the target of REST is
-as Fielding pointed out in his dissertation- that any client can talk with
any server. When using standardized headers for things they are not expected
to be used for, or when using non-standardized headers, this will fail. I
agree that the link header is the perfect solution if the links cannot be
put inside of the entity (this is the explanation of the existence of the
header, according to the RFC) -- but not as long as it is not part of the
http standard.
So in fact I do not agree that I am "wrong" in sum, but only in the specific
question of whether there can be links in headers. Sure there can be. But it
will be of no benefit for a system that tends to be compatible with foreign
clients, which is part of the definition of REST.
As you see, I just think in wider dimensions, where "wrong" in the inner
sense might be "not so wrong" in the wider sense. ;-)
From: Paul.Sandoz_at_Sun.COM [mailto:Paul.Sandoz_at_Sun.COM]
Sent: Dienstag, 16. Februar 2010 07:36
To: users_at_jersey.dev.java.net
Subject: Re: [Jersey] What HATEOAS actually means
Hi Markus,
Respectfully, you are still wrong.
The current Link draft specification and the HTTP specification are quite
clear on the matter. And Roy, in another email, has also clarified this too
with respect to those specifications:
Link is part of the representation metadata (that's its whole reason to
exist).
Content-Location is representation metadata for the URI of this content.
Location is a response header used as part of the redirect aspects of
HTTP.
All three are data for describing transitions from here to there, when
used
according to the HTTP standards, and thus are part of the hypertext as far
as REST is concerned. This is necessary for the support of hypermedia
representations in a format that does not allow embedded links or
overlays,
and for a lot of other reasons that I have no time to describe right now.
I consider that this particular aspect of hypermedia is now suitably
clarified and requires no further discussion on this list.
Paul.
On Feb 15, 2010, at 7:41 PM, Markus Karg wrote:
Paul,
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
http://roy.gbiv.com/untangled/2008/rest-apis-must-be-hypertext-driven 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
"Protocolinformation".
Also I never said that http forbids to send links in headers. This is valid
http. But it is neither HATEOAS nor REST.
Regards
Markus
From: Paul.Sandoz_at_Sun.COM [mailto:Paul.Sandoz_at_Sun.COM]
Sent: Montag, 15. Februar 2010 11:46
To: users_at_jersey.dev.java.net
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:
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
<
http://tools.ietf.org/html/draft-nottingham-http-link-header-07#ref-W3C.REC
-html401-19991224> ], and more
recently in Atom [RFC4287 <
http://tools.ietf.org/html/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