> > 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?).