On Jul 26, 2011, at 1:57 PM, Markus KARG wrote:
>> 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?
> 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?
-- Santiago