On Tue, Feb 16, 2010 at 11:38 AM, Markus Karg <markus.karg_at_gmx.net> wrote:
>> > Do you now understand why I say that the only valid place is inside
>> of the
>> > entity (because the entity format is known to the client, while the
>> use of
>> > the headers is not)?
>> >
>> Surely if you can teach a client about the links it might find in an
>> entity you can also teach it about links it might find in headers too ?
>> Actually this seems essential when certain headers are considered part
>> of the hypermedia.
>
> You misunderstood my point: If I am sending links as <A> in HTML, then a
> browser will understand HTML and such will understand <A> and find the
> links. It plays no role where in the HTML the link is used or for what
> reason. Any browser can find any link in any HTML document sent by any
> server, without the need to teach the client anything. But least browsers
> will have any real interest in http "Link" headers, besides few special ones
> like those for declaring RSS feeds. So if you like to turn a generic REST
> client into a browser, you just need to provide a plugin for rendering HTML.
> That kind of plugin will be "MIME-related". But this plugin will not be
> enough if your links are not in the <A> headers but elsewhere. But where? So
> as you say, you have to teach the client *which* headers to check. But how?
> A "MIME-related" plugin will not provide the solution, so in fact you would
> need a plugin that teaches things special to Jersey! Which client will be
> able to understand such a plugin, besides the Jersey client? None! So the
> only solution can be: Either have the links in the documents, or solely (!)
> use the "Link" header and *hope* that the client is more clever than the
> everage browser and actually takes care of the "Link" header in general, but
> not just a few that are hard corded (like the RSS links in current browsers)
> (noticed that meanwhile you convinced me that "Link" is a valid place for a
> link?).
There is an amusing symmetry between the way that links are handled in
Atom and the current discussion about Link headers. In an Atom entry,
the standard-defined <link> elements are *external* to the <content>
element that contains the representation, just as the Link: header
makes them external to the message body in an arbitrary HTTP response
:-).
Markus, you seem to be missing a key part of Roy's clarification: the
metadata *is* part of the representation of a resource. All of it,
not just some of it. After all, if you are just looking at an HTTP
message body, how do you even know what media type it is? Yep ... go
look at the Content-Type header.
How is the representation encoded (Content-Encoding)?
What language is it written in (Content-Language)?
Is there a canonical URI for this resource that I should be using
(Content-Location)?
How big is it (Content-Type)?
Can I cache it (Cache-Control)?
Metadata is your friend. Indeed, it is difficult to understand how
one could compose a generic client that didn't understand at least all
the Content-* headers.
I agree with you that embedded links are nice (from an aesthetic point
of view), but they are not always practical. I'm not always in
control of the format of the message body itself (a bitmap image
doesn't provide much opportunity for injecting links; neither does an
XML message conforming to some application schema that didn't include
them), so I still need a way to express the relationships. Given that
a client needs to deal with metadata anyway, expressing links there
isn't good or bad, it is just different.
Craig