jsr339-experts@jax-rs-spec.java.net

[jsr339-experts] Re: [jax-rs-spec users] Re: Hypermedia - Take 2

From: Santiago Pericas-Geertsen <Santiago.PericasGeertsen_at_oracle.com>
Date: Tue, 26 Jul 2011 12:00:38 -0400

Hi,

 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.

-- Santiago

On Jul 25, 2011, at 5:15 PM, Sergey Beryozkin wrote:

> Hi
>>>> BTW, as the web
>>>> is the prototype of REST, and the web typically is using relative
>>> URLs in a
>>>> massive way, we should really discuss the benefit of relative URLs
>>> (better
>>>> security as both parts must be in the same domain, less data to
>>> transfer and
>>>> process). Every browser comes with a resolver for that, so it should
>>> be
>>>> fairly easy for the Client API implementation to resolve relative
>>> URLs
>>>> received in responses (as it knows the base URL that the request was
>>> sent
>>>> to).
>>> I guess if HTML representation is returned than yes, relative links
>>> should world OK, otherwise it's an extra effort for the client code to
>>> deal with such rel links ? We can get URIs relative to the base URI,
>>> but
>>> also perhaps relative the currentURI, example, GET has been made after
>>> baseURI + several path()s ? I can imagine a large payload duplicating
>>> the info like "http://host:port/order" - for cases like this we should
>>> encourage users use relative links if feasible.
>>> By the way, I think there should be a way to express that a response
>>> xml
>>> representation needs to have xml:base attribute for resolving relative
>>> links
>> For what do we need that base URI? I mean, if my browser does a request to
>> http://www.foo.de/bar/x/y/z.html, and that html contains <img src="i.png"/>
>> then all browsers on this earth are able to assume a base URI of
>> http://www.foo.de/bar/x/y. So why should the client engine behave anything
>> different? And what do you mean with "additional effort" -- we just talk
>> about splitting a path from a file in world of 3+ GHz MultiCore laptops.
>> Have you every computed the actual costs you are complaining about? ;-)
> LOL :-) I think it's 2nd time I'm getting this message - do I sound like I'm complaining :-) ?
> Anyway, you did not comment on what I said about the ambiguity to do with getting a payload with relative links after
>
> link.request().get()
> and
> link.path("bar").request().get()
>
> should the client resolve the rel links against
>
> basePath or basePath + "bar" ?
>
> I'm not saying we should not support relative links, I just feel absolute URIs are more interoperable which is important
>
> Cheers, Sergey
>
>> Regards
>> Markus
>
> --
> Sergey Beryozkin
>
> http://sberyozkin.blogspot.com
> Talend - http://www.talend.com
>
>