On Feb 16, 2010, at 7:04 PM, Markus Karg wrote:
>> [..]
>> 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!
Just add them in - are declare that any of the IANA link rels might be used.
> So
> which of these clients will check for links in the "Link" header, which is
> not standardized yet?
Only those that you program to do that. But that is also true for media types, AtomPub categories, NewsML categories or NITF topics etc.
> Which of them will check for links in "Location" or
> "Content-Location", as those are intended for different use? NONE!
Umm - a client that implements HTTP 1.1 better checks and reacts on those headers correctly. (And, BTW, this is what the framework IMHO must enforce!)
The reaction to those headers (be it implemented or configured) will influence how the user agent reaches the next steady state.
> So the
> information gets just lost! That's the answer why a browser expects to find
> links in the entity EVER and ONLY.
I never tested, but I would actually expect some browser out there to e.g. load a CSS style sheet linkt to from a Link header. The Mozilla and Opera guys are often quite early with that kind of stuff.
>
> The situation would be totally different as soon as the "Link" header would
> be standardized!
You can also write a client that sends request-fo-change tickets to a helpdesk for any unknown thing it comes across to initiate that someone takes care of bringing the clients up to date or at least to think about leveraging that new piece of functionality.
> 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).
But in the end - who cares? There is no harm done by Link headers. However, I still agree that one should focus on documents and not on stuffing a domain model into a bazillion of link headers :-)
But a link like Link: <./props?lock>;rel=lock [1] to tell clients where a lock for a resource is is much better located in the header than added to any media type in use.
[1] Adapted from the mind blowing (for me at least) posting:
<
http://www.xent.com/pipermail/fork/2001-September/004712.html>
>
> 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)?
>
I understand what you say, but it does not matter what some clients might do and might mot do as long as the overall architecture enables them to evolve to support just what the need to support. And that is what REST is particularly good at (and what should be leveraged inside the enterprise, too. Although confusing to most CxOs in the beginning :-)
Jan
> Regards
> Markus
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe_at_jersey.dev.java.net
> For additional commands, e-mail: users-help_at_jersey.dev.java.net
>
-----------------------------------
Jan Algermissen, Consultant
NORD Software Consulting
Mail: algermissen_at_acm.org
Blog:
http://www.nordsc.com/blog/
Work:
http://www.nordsc.com/
-----------------------------------