Im with Paul on this. The API should abstract away the common URL
encoding/decoding step.
It's not that hard to provide an undecoded option:
@RawUriParam("name") String undecodedName
Dhanji.
On 6/22/07, Paul Sandoz <Paul.Sandoz_at_sun.com> wrote:
>
> Julian Reschke wrote:
> > Hi,
> >
> > I think this kind of proves that the URI template internet draft needs
> > to be finished, and then, the relation between JSR-311's templates and
> > the ones described by the IETF spec needs to be clarified.
> >
>
> Agreed.
>
>
> > Right now,
> > <
> http://bitworking.org/projects/URI-Templates/draft-gregorio-uritemplate-00.html
> >
> > seems to speak about URIs, nothing else. So you can't have an unescaped
> > blank space, nor non-ASCII characters. It seems to me that this is what
> > the current RI should implement.
> >
>
> That seems reasonable.
>
>
> > Which also means that unescaping of templated values needs to be done in
> > a separate step. That may be a bit ugly, but I really prefer that in
> > comparison to messing around with the template format.
> >
>
> Just because the template requires escaping (for 'conformance' reasons)
> does not mean the template values accessed by the developer need be. A
> similar case can be made for annotations that require a conformant URI,
> the path can be accessed as a decoded values (URI.getPath).
>
> Note that it is possible to support types other than String [1] with
> @UriParam, thereby requiring decoding:
>
> Binds a method parameter, class field or property to a URI template
> parameter value. The class of the annotated parameter, field or
> property must have a constructor that accepts a single String
> argument, or a static method named valueOf that accepts a single
> String argument (see, for example, Integer.valueOf(String)).
>
>
> If we don't decode then a developer will spend time debugging a problem
> to find that funny characters are present in the template values. On the
> hand if we do decode a developer will spend time debugging URI creation
> exceptions. Both are a source of nasty sleeper bugs :-(
>
> However, I would think it highly likely that if a developer uses
> UriParam or QueryParam that they want to do something useful with it
> (e.g. as a DB key or SQL query) thus decoding will have to be done and
> to tell the developer that they have to do this seems contrary to a
> developer-friendly API. In either case the decoded value might be used
> as part of URI creation...
>
>
> IMHO I think we need to investigate techniques for URI creation and
> manipulation given the knowledge that the developer is likely to prefer
> working with decoded values (while not pulling the rug from under the
> developers that need to work with escaped values). For example, we could
> expose a URI template class that supports the parsing and creation of
> URIs, it may be possible to get a URI template from the current resource
> class (on itself or the ones for the next matches e.g. to use for URI
> creation) etc.
>
> Paul.
>
> [1] https://jsr311.dev.java.net/releases/0.1/javax/ws/rs/UriParam.html
>
> >
> >
> > Best regards, Julian
> >
> > (*) we could use IRI templates, instead of URI templates, but then we'll
> > still have to take care of characters not allowed in IRIs, such as SP,
> > "{", "}", "/" and so on...
> >
>
>
>
> --
> | ? + ? = To question
> ----------------\
> Paul Sandoz
> x38109
> +33-4-76188109
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe_at_jsr311.dev.java.net
> For additional commands, e-mail: dev-help_at_jsr311.dev.java.net
>
>