On 10/23/2012 2:52 PM, Marek Potociar wrote:
> That's not orthogonal I'm afraid. If you used UriBuilder to produce a
> URI based on an matching a single request against your resource
> hierarchy using the values of @Path annotation, you MUST (IMO) be able
> to re-construct the original request using the values injected into
> @PathParam fields. E.g.
>
> @Path("root/{a}")
> class Resource {
> @Context UriInfo uriInfo;
>
> @GET
> @Path("{b}")
> public boolean get(@PathParam("a") String a, @PathParam("b") String b) {
> return UriBuilder.fromPath("root/{a}").path("{b}").build(a,
> b).toString().equals(uriInfo.getPath());
> }
> }
>
> This must IMO return true also for requests like:
>
> GET /root/foo%2Fbar/baz
>
> Note that in the above, the value of injected parameter a will be
> "foo/bar". Maybe you see it now. The above should also work for
> path(Class) and path(Method), of course. And obviously this behavior is
> also anticipated and reflected in the Client API...
>
But you are forgetting:
GET /root/foo/bar/baz
@Path("/root/{a}")
class Resource {
@GET
@Path("{b: .*}")
public boolean get(...what you had before...
}
In this case the '/' is not encoded. If the client is getting a
template, it has no idea if the server is expecting '/' to get encoded
or not. IMO, '/' is a legal character so encoding '/' should be an
extreme edge case.
Bill
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com