> >> 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.
> >
> > It's always enlighting to ask the master himself! So I am wrong,
> there are
> > few (exactly these) headers that may contain links -- besides the
> entity
> > itself. Great! But how shall a generic client (a) know which headers
> are
> > used to transfer the link information and (b) that it has to check a
> header
> > that is not even standardized?
>
> A client can only look for headers (and media types for that matter)
> that it knows about.
>
> How does the client developer know what headers to look for when coding
> to pursue a certain goal?
Exactly my question! "Link" is not yet part of the http standard!
> Yes, the client needs some understanding of
> the set of hypermedia semantics the server makes use of.
>
> Web browser implementers know that this set is HTML, stylesheets,
> images etc.
>
> AtomPub client developers know that this set is application/atom+xml,
> application/atomsvc+xml and application/atomcat+xml
>
> OpenSearch client developers know that this set is
> application/opensearch+xml, application/atom+xml and
> application/rss_xml
Okay, this list contains MIME type -entities!- only, but not headers! So
which of these clients will check for links in the "Link" header, which is
not standardized yet? Which of them will check for links in "Location" or
"Content-Location", as those are intended for different use? NONE! So the
information gets just lost! That's the answer why a browser expects to find
links in the entity EVER and ONLY.
The situation would be totally different as soon as the "Link" header would
be standardized! As Mr Fielding explained yesterday, it is there for those
media types that have no ability to store links in entities (what on the
other side means, that it makes less sense if the entity *can* store links).
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)?
Regards
Markus