>>> Me too. :) decoded keys always.
>>>
>> I assumed and implemented encoded keys and values for
>> UriInfo.get*Parameters(true) and UriInfo.getPathSegments(true).
>> Namely that you if ask for something in encoded form you get
>> everything in encoded form. This reduces possible sources of
>> confusion and bugs and the main idea of encoded form was so that a
>> more advanced developer could work consistently in encoded form for
>> all such information extracted from the URI.
>> UriBuilder.queryParam encodes the value and name if the encode
>> property is set to true, otherwise validates the value and name if
>> set to false. If query keys are decoded but query values are not
>> then it is hard to use UriBuilder.queryParam consistently with
>> UriInfo.getQueryParameters(false).
>
> Yeah, I guess you're right. My thought was, why would anybody ever
> encode a key to access a specific value in the map? In general, I
> don't see how these encoded maps would be very useful. Can you
> provide a use case?
>
Having thought about this some more I agree with Paul, if a developer
is working in encoded space its more natural to encode both keys and
values. I'll update the javadoc to make this explicit.
>> Looking more closely i found some issues because the *Param names
>> are not specified to be in encoded or decoded form, and i did not
>> assume either way when implementing.
>> The JavaDoc does not define if @*Param names should be in encoded
>> or decoded form. Same goes for @DefaultValue. Note that @Encoded
>> does not apply to values of @Path, for example:
>> @Path(value="x%20y", encode=false)
>
For consistency with @Path we need to add a:
boolean encode() default true;
property to each of @PathParam, @QueryParam, @MatrixParam and
@DefaultValue.
>> We also need to specify the encoded/decoded form for:
>> UriInfo.getAncestorResourceURIs
>> and perhaps be consistent with other methods with a boolean
>> parameter.
>
Agreed, I'll add that.
> Except for URIBuilder, why even have the option to have things
> encoded? I don't see developers wanting to use it very much, if at
> all. If they want things encoded, its just as easy to call
> URLEncoder.encode(). Which would be a rarity in the first place.
>
> So, my vote is to remove @Encoded and all encoding methods except
> for URIBuilder.
>
The current APIs came about as a solution to issue 3, see the
discussion thread starting at:
https://jsr311.dev.java.net/servlets/ReadMsg?list=dev&msgNo=477
for a variety of use cases and opinions. I can understand the
temptation to do everything in decoded space but there were good uses
on both sides of the argument which is why we ended up where we are.
Marc.
---
Marc Hadley <marc.hadley at sun.com>
CTO Office, Sun Microsystems.