> >> 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.
Sorry, didn't actually understand what you like to say. Can you elaborate on
that please?
> > 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.
Ok, I am writing a generic REST client, just as a browser is one. And now?
Which ones to program in? All? Is this scalable? No. There is no solution
but to reduce to either the document entity plus the "Link" header.
> But that is also true for media
> types, AtomPub categories, NewsML categories or NITF topics etc.
This is wrong, as it would be rather easy to have a plugin for MIME
renderers, while you won't find a key for plugins to start for headers.
> > 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!)
Ok, which of them, besides "Link"? And if it is *only* link, there is no
need to discuss about headerS (plural) as you already convinced me that
"Link" is a valid place.
> The reaction to those headers (be it implemented or configured) will
> influence how the user agent reaches the next steady state.
Can you provide an example? I just don't understand what the benefit of
additional headers (besides "Link") is.
> > 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.
Add any other HTML document as a relation, name the relation "shipment" and
put a http Link on it. What does your browser do?
Now put the same link as <A> in the HTML document. See the difference?
I wonder if actually the http link will be presented to you in any way
unless it is a feed link.
Obviously the browser is not completely extendible since it doesn't present
you all links, but just the ones itself knows about -- while it would
present any unknown MIME to you (even if it does it just in the form of
"please save this, I have no renderer for it" dialog).
This is what I mean with: The link is just lost, as the client doesn't care
about it!
> >
> > 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.
Actually I do not understand what you like to say or how that is related to
my thesis that generic REST clients will typically ignore links in headers,
unless the world agrees on using exactly the "Link" header?
> > 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.
...besides possible redundancy, including the known possible negative side
effects.
> However, I still agree that one should focus on documents and not on
> stuffing a domain model into a bazillion of link headers :-)
Why argueing then? ;-)
> 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.
Why? And is it really needed to tell a client this (I'm a bad boy I know,
but let me be the devil's advocate and tell the thesis that WebDAV will
solve that...). ;-)
> [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.
Yes, if you write a client for exactly that web service, but not if you are
writing a generic client. Do you have a special browser for each web site?
Not me.
> 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
> :-)
Didn't get that point, actually. Can you explain?
>
> 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/
> -----------------------------------
>
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe_at_jersey.dev.java.net
> For additional commands, e-mail: users-help_at_jersey.dev.java.net