On Nov 26, 2012, at 11:21 PM, Santiago Pericas-Geertsen <Santiago.PericasGeertsen_at_oracle.com> wrote:
>
> On Nov 26, 2012, at 4:34 PM, Jan Algermissen <jan.algermissen_at_nordsc.com> wrote:
>
>>
>> On Nov 26, 2012, at 9:05 PM, Santiago Pericas-Geertsen <Santiago.PericasGeertsen_at_oracle.com> wrote:
>>
>>>
>>> On Nov 26, 2012, at 2:14 PM, Jan Algermissen <jan.algermissen_at_nordsc.com> wrote:
>>>
>>>>
>>>> On Nov 26, 2012, at 6:05 PM, Santiago Pericas-Geertsen <Santiago.PericasGeertsen_at_oracle.com> wrote:
>>>>
>>>>>
>>>>> On Nov 26, 2012, at 10:51 AM, Jan Algermissen <jan.algermissen_at_nordsc.com> wrote:
>>>>>
>>>>>>
>>>>>> On Nov 26, 2012, at 4:38 PM, Santiago Pericas-Geertsen <Santiago.PericasGeertsen_at_oracle.com> wrote:
>>>>>>
>>>>>>>
>>>>>>> On Nov 20, 2012, at 4:14 PM, Jan Algermissen <jan.algermissen_at_nordsc.com> wrote:
>>>>>>>
>>>>>>>>
>>>>>>>> On Nov 16, 2012, at 11:11 PM, Santiago Pericas-Geertsen <Santiago.PericasGeertsen_at_oracle.com> wrote:
>>>>>>>>
>>>>>>>>>
>>>>>>>>> On Nov 16, 2012, at 4:46 PM, Jan Algermissen <jan.algermissen_at_nordsc.com> wrote:
>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> On Nov 16, 2012, at 10:40 PM, Santiago Pericas-Geertsen <Santiago.PericasGeertsen_at_oracle.com> wrote:
>>>>>>>>>>
>>>>>>>>>>> Jan,
>>>>>>>>>>>
>>>>>>>>>>> My gut reaction is that we should not absolutize URIs on the server, it can lead to all sorts of problems (clustering environments, etc.).
>>>>>>>>>>
>>>>>>>>>> Yes. That was what I came to, too (in my However(!) sentence)
>>>>>>>>>
>>>>>>>>> I see.
>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>> We should instead have the notion of a base URI on the client, and have the client API do the work, just like a browser.
>>>>>>>>>>
>>>>>>>>>> That is the problem. The existing base URI 'determining' algorithm will lead to anything, but never to the JAX-RS application path.
>>>>>>>>>
>>>>>>>>> I didn't mean we'd do this automatically. We should ask the "human" developer for help :)
>>>>>>>>>
>>>>>>>>>> I am now thinking that there is 'concept' missing - I'll think about it and see if I get an idea of it, at least.
>>>>>>>>>
>>>>>>>>> Sounds good.
>>>>>>>>
>>>>>>>> What about putting an alternative Link/Uri -fromResourceXX() base URI in ApplicationConfig?
>>>>>>>>
>>>>>>>> @javax.ws.rs.ApplicationPath("resources")
>>>>>>>> @javax.ws.rs.BaseUri("http://service.ex.org/erp-system/api")
>>>>>>>> public class ApplicationConfig extends javax.ws.rs.core.Application {
>>>>>>>>
>>>>>>>> }
>>>>>>>>
>>>>>>>> Not ideal, but maybe it triggers other thoughts.
>>>>>>>
>>>>>>> I don't think this will generally work in a clustering environment (with load balancers, etc.). It may work if that info is in a deployment descriptor, but having to recompile my app just to deploy it correctly is clearly undesirable.
>>>>>>>
>>>>>>> What about introducing the notion of a base URI as part of the Client API?
>>>>>>
>>>>>> That won't work because the base URI for relative URI references in HTTP responses is already defined by the HTTP & friends spec stack. This is nothing you can override or tamper with.
>>>>>
>>>>> I don't understand this, can you send some links explaining that?
>>>>>
>>>>>> This is why having Link.fromXXX produce relative URI refs makes the whole thing useless. You definitely need to prepend a base URI. And for that you need to create a new Link object via a roundtrip through UriBuilder.
>>>>>
>>>>> Browsers resolve relative URIs all the time, so it can't be useless. There are various mechanisms for converting a relative URI to an absolute one. I believe this is the one that applies to our client API:
>>>>>
>>>>> http://tools.ietf.org/html/rfc3986#section-5.1.4
>>>>
>>>> No, this section only applies if the other's do not. You have to look at 5.1.1 to 5.1.3.
>>>
>>> I don't see how 5.1.1 or 5.1.2 apply here. As for 5.1.3, I understand how this may apply but I don't see the problem of overriding
>>
>> ???
>>
>> It is not up to you to decide. 5.1.3 will allways apply in an HTTP response context (if 5.1.1 and 5.1.2 don't). It already is the default.
>
> That is certainly the case in general.
What do you mean by 'in general'? Are you suggesting the URI spec applies sometimes and sometimes not?
> I was talking specifically about clients built using our Client API, in which case we can certainly override this.
How would you override the URI spec rules for resolving a relative URI reference? What has the client API got to do with it?
> But, of course, some arbitrary HTTP client out there that attempts to follow link headers will not work
That sentence makes no sense. Sorry. I have no clue what you are talking about.
A Link object created from Link.fromXXX() the way it is designed now will never be useable in an HTTP response because the relative URI references created from it and placed in the response entity (header or body) will never resolve to the correct URI.
You cannot *override* the resolution rules in the URI spec for relative URI references.
I am honestly totally baffled about they way (you seem to) approach this issues. I looks as if you somehow assume to have control over the client to tamper with the resolution rules. If that is so, that would scare me.
> (don't know of any at the moment). Hence, my other proposal below ...
>
>>> The only other alternative that I can think of is to generate all the server URIs relative to the request URI.
How would that work?
Jan
>>> This may work but adds complexity to the implementation and application. Additionally, on the client API, we may need to eagerly absolutize URIs or store information to co-relate request and responses.
>
> What about this then?
>
> -- Santiago
>