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

[jsr339-experts] Re: UriBuilder, forward slashes, path and segments

From: Markus KARG <markus_at_headcrashing.eu>
Date: Sun, 3 Jun 2012 10:26:45 +0200

Sergey,

I did hope that I'm not the only one having to watch for this issue. ;-)

Clearly separating template building API from data provision API makes use
so much easier that I do actually not understand that anybody will not vote
for this. But in the end it is Oracle who decides, so I can just reply
myself again and again and cast my vote in the end.

As I stated months back already, it seems some members should look the API
more through the eyes of Java programmers and less through the eyes of
implementation vendors or web gurus. Many of the past discussions would not
have happened if people would try to make things as most simple for the
users of the spec, instead of making most of their own position.

Regards
Markus

> -----Original Message-----
> From: Sergey Beryozkin [mailto:sberyozkin_at_talend.com]
> Sent: Freitag, 1. Juni 2012 16:09
> To: jsr339-experts_at_jax-rs-spec.java.net
> Subject: [jsr339-experts] Re: UriBuilder, forward slashes, path and
> segments
>
> Markus,
>
> I did hope you'd reply :-)
> On 01/06/12 14:36, Markus KARG wrote:
> > Gentlemen,
> >
> > please keep things simple.
> >
> > Strings provided by .path() are template placeholders, while Strings
> > provided by .build() are variables content (to be filled into the
> > template placeholders).
> >
> > So if anybody does NOT expect that .path("{a}").build("a/b")
> > effectively produces "a%2FB" in the end has simply done a programming
> fault.
> >
> > Certainly you can punish everybody else by providing another
> > parameter, but in fact, omitting the parameter SHOULD break any
> > existing code that expects
> > .build("a/b") is NOT providing "a%2FB" as this assumption was simply
> a
> > wrong understanding of the sense of template placeholders and
> variables content.
> >
> I have no problems with the way "/" is managed now.
> I thought it was a bit counter-intuitive to get "/" in "a/b" being not
> encoded in cases where someone who builds a URI against the target
> known to listen at "/{a}/c".
>
> Basically, I'm saying that a service developer will not expect "/{a}/c"
> matching "a/b/c", produced by uriBuilder.path("{a}/c").build("a/b").
> While the client developer may find it confusing.
>
> Not a huge problem I guess.
>
> Sergey
>
> > Regards
> > Markus
> >
> >> -----Original Message-----
> >> From: Sergey Beryozkin [mailto:sberyozkin_at_talend.com]
> >> Sent: Freitag, 1. Juni 2012 12:43
> >> To: jsr339-experts_at_jax-rs-spec.java.net
> >> Subject: [jsr339-experts] Re: UriBuilder, forward slashes, path and
> >> segments
> >>
> >> On 01/06/12 11:26, Sergey Beryozkin wrote:
> >>> Hi
> >>>
> >>> I remember the lively thread we had awhile back about encoding "/"
> >>> passed to UriBuilder path and segment methods as if it was
> yesterday
> >>> when we talked about it :-), but I have to admit I've no idea what
> >> the
> >>> actual conclusion to it was, sorry :-)
> >>>
> >>> I've just had a related query on the users list and I'm coming to
> >>> the conclusion that the encoding of "/" should be different
> >>> depending on when it is passed to UriBuilder, in case of path()
> methods:
> >>>
> >>> 1. UriBuilder.fromPath("").path("a/b").build()
> >>> should produce "a/b" - as per the JavaDocs of path(...)
> >>>
> >>> 2. UriBuilder.fromPath("").path("{a}").build("a/b")
> >>> should produce "a%2Fb"
> >>>
> >>> The reason I think the 2nd variant should produce "a%2Fb" is
> because
> >>> producing "a/b" will be inconsistent with the fact the the matching
> >>> algorithm will not actually match "a/b" when we have @Path("{a}")
> >>> and I think it should kind of work both ways.
> >>>
> >>> I'm not sure all will agree as one can imagine it can break some
> >>> existing code, but please imagine JAX-RS 2.0 Client code doing 1.
> >>> above and working against the endpoint with @Path("{a}") and then
> >> repeating 2.
> >>> and failing against the same endpoint
> >>>
> >> Actually. In both cases, as it currently stands, we will get "a/b"
> >> and that will fail to match against @Path("{a}") but I think that
> the
> >> user expectation in the 2nd case will likely be for it not to fail.
> >>
> >> Marek, I recall you suggested to add an optional flag to build(), to
> >> influence whether the "/" should be encoded or not in cases like
> >>
> >> UriBuilder.fromPath("").path("{a}").build("a/b");
> >>
> >> example
> >>
> >> UriBuilder.fromPath("").path("{a}").build(true, "a/b");
> >>
> >> produces ("a%2Fb") ?
> >>
> >> thanks, Sergey
> >>
> >>> For segments, the forward slash has to be encoded all the time:
> >>>
> >>> 1. UriBuilder.fromPath("").segment("a/b").build()
> >>> should produce "a%2Fb" - as per the JavaDocs of segment(...)
> >>>
> >>> 2. UriBuilder.fromPath("").segment("{a}").build("a/b")
> >>> should produce "a%2Fb"
> >>>
> >>> I do not see any ambiguity here
> >>>
> >
>