> >> Re-inforcing Sergey's point in different terms, the browser can do
> >> this because the next request is always associated with the last
> >> response. The Client API allows you to break this association, so
> it's
> >> not always possible to absolutize your links in the same manner.
> >>
> >> For example,
> >>
> >> Client c = .
> >> Order o = c.request(".").get().invoke(Order.class);
> >>
> >> // Execute some other requests using "c" .
> >>
> >> // How is the relative o.getCustomer() URI resolved here?
> >> Customer cust =
> >> c.request(o.getCustomer()).get().invoke(Customer.class);
> >>
> >> We would need to use HttpResponse, and somehow create the next
> request
> >> based on that object for this to work. Using absolute links by
> default
> >> seems like the better option. It may be possible to handle this
> >> scenario better in a high-level API.
> >
> > Again, please check my original proposal
>
> Do you have some cycles to put it in wiki form?
Do you think it is worth the effort? I mean, it seems that my proposal has
no majority anyways.
> > which said that I do not keep any
> > URIs but return JAXB types. That means, the first above invoke
> returns a
> > Order and that Order has a Customer (not an URI -- this is already
> > resolved). So a o.getCustomer() returns a customer which is already
> loaded
> > *before* you obtain the Order. You never get that URI of the customer
> in my
> > proposal. So the second invocation is not needed.
>
> So you get a representation with URIs and resolved them eagerly before
> the application gets to the parts? I thought the whole point was to
> resolve the parts _on demand_. That's certainly what a browser would
> do. I fail to see the value of this approach. Could you explain?
Yes, the representation is using relative URIs to reduce message size, and
the unmarshaller is eagerly resolving those so the JAXB instance will be a
fully useable document. The reason is that the proposal is about structural
links only, and in our experience, most links are actually followed rather
soon. Our test users told us that they rather like to have a document to
edit which already contains all references, so they later can drop the LAN
cable and use the document locally (our customers are not always online as
they are not typical office users but mobile workers). If we would use on
demand resolution this would not work obviously but it enforces always
online use mode (which is a problem for our customers). Another negative
effect of on demand resolution is that the data used by our customers is
rather "tightly bound" and the test users didn't like that the referenced
data has changed since downloading the master document; they liked it more
to have some kind of "weak snapshot", i. e. downloading documents that have
more or less the same timestamp. So we developed our application to download
eagerly, and on that real world experience we provided the proposal. But I
understand that other users might not have that need. BTW, about browsers: I
don't know whether it's just my browser, but mine is loading ALL images at
once when I open a HTML page. Yours is not? ;-)
Regards
Markus