[jsr339-experts] Re: [jax-rs-spec users] Re: Re: Re: Re: Re: Re: Are Links build with fromReosurce or fromResourceMethod are useful at all?
- From: Jan Algermissen <jan.algermissen@...>
- To: jsr339-experts@...
- Subject: [jsr339-experts] Re: [jax-rs-spec users] Re: Re: Re: Re: Re: Re: Are Links build with fromReosurce or fromResourceMethod are useful at all?
- Date: Tue, 27 Nov 2012 15:50:06 +0100
On Nov 27, 2012, at 3:14 PM, Santiago Pericas-Geertsen
> On Nov 26, 2012, at 6:30 PM, Jan Algermissen <jan.algermissen@...> 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.
I pursued this because I try to avoid such ideas 'leaking' from one of the
most prominent REST frameworks.
> besides, the proposal has issues.
> The one thing we agree on is that we need to do something about these
> relative URIs, so let's move on that (hopefully without anyone getting
> scared :).
>>> (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
> 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.
> -- Santiago