On Nov 27, 2012, at 9:50 AM, Jan Algermissen <jan.algermissen_at_nordsc.com> wrote:
>
> On Nov 27, 2012, at 3:14 PM, Santiago Pericas-Geertsen <Santiago.PericasGeertsen_at_oracle.com> wrote:
>
>>
>> On Nov 26, 2012, at 6:30 PM, Jan Algermissen <jan.algermissen_at_nordsc.com> wrote:
>>
>>> 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.
>>
>> It's not even worth pursuing this discussion, I feel just as baffled at some of your responses;
>
> Well, it *looks* as if you suggest to couple client and server on a shared knowledge about a base URI. Working around the URI spec. It also looks as if you suggest to couple client and server to JAX-RS implementations because no other client framework besides JAX-RS client would ever have the 'overide base URI' feature.
That's exactly what I proposed initially without thinking the implications of it. And why I later agreed that it was not a complete solution.
>>>> (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?
>>
>> One way could be to pass the request URI to the Link.Builder and ensure the links are relativized as part of the build process.
>
> But what if one does not create the link in a request context? E.g. in a provider?
@UriInfo can be injected anywhere. In fact, perhaps Link.Builder should use what's provided by @UriInfo by default.
>> Let's recap the options discussed so far:
>>
>> (i) Use @BaseUri on Application subclass.
>>
>> + straightforward semantics
>> + easy to implement
>> - requires re-compilation to change base URI
>> - may be only reason to define an Application subclass
>
> +1 on the judgement. Yes, the solution is good and bad :-)
>
>>
>> As stated before, I think this solution would be better if we had a DD. But, perhaps this is something we can go with now and improve if when/if we introduce a DD?
>>
>> (ii) Compute relative URIs based on request URIs
>>
>> + no need to specify base URI
>> - harder to implement
>> - links in responses need a context (base URI) for resolution
>
> Links in responses *always* have exactly one base URI per the rules in the URI spec. (That is our disconnect above, I believe).
>
> (ii) would work if we'd tie Link (or Link.toString()) to a requets context. Not sure how/if that works. But (ii) is sort of cleaner, IMHO.
Maybe they are not mutually exclusive. We can support (i) right away while we continue to iron out (ii) ...
Any other opinions (or different suggestions) on (i) and (ii) from other experts?
-- Santiago