[jax-rs-spec users] [jsr339-experts] Re: Re: UriTemplate API?

From: Marek Potociar <>
Date: Thu, 21 Feb 2013 14:16:48 +0100

On Feb 20, 2013, at 6:23 PM, Sergey Beryozkin <> wrote:

> Hi
> On 20/02/13 17:08, Marek Potociar wrote:
>> Hello experts,
>> Please review the issue that has been recently filed:
>> In summary the user wants to be able take a URI template, e.g.
>> "{name}/age/{age}" and then take a URI, e.g.
>> "" (guess who...) and extract the
>> parameter values information into a Map<String, String> instance.
>> The solution may look like:
>> UriBuilder builder =
>> UriBuilder.fromUri("{name}/age/{age}");
>> UriTemplate template = builder.template();
>> Map<String, String> params = new HashMap<String, String>();
>> if (template.match("", params)) {
>> params.put("name", "Alois");
>> URI uri = builder.buildFromMap(params);
>> ...
>> }
>> The above requires following API changes:
>> * introduce UriTemplate to represent, well, URI templates...
>> * add ability to get UriTemplate instances from UriBuilderand WebTarget
>> * expose the boolean UriTemplate.match(URI, Map<String, String>)
>> method as part of the UriTemplate API.
>> Now, finally, my question is:
>> Q1. Do you think the above API would be useful?
>> Q2. Is it something we should still try to add into JAX-RS 2.0, given
>> where we are?
> On the server side, UriInfo.getPathParameters will give it to us, thus I'd prefer not to rush at this stage with the introduction of UriTemplate - it can become handy but IMHO quite a bit of thinking may needed to figure out how exactly this interface may look like, for example, should it then also offer say a method getNumberOfTemplateVars, etc...

The use case is primarily for client side. The API as proposed is inspired in an existing Jersey API that has been stable for quite a while... (years)

> By the way, I haven't guessed yet who opened it, looking now :-)

It has been opened by an IDE developer who is currently forced to develop his JAX-RS support with use of non-portable Jersey APIs.

Btw. I'm not pushing for putting this in 2.0. I'm asking EG if you think it would make sense - e.g. if you saw similar use cases or users asking for it. The only reason I still am willing to consider this for 2.0 is that we have the infrastructure ready in the RI and the change is isolated, so it would not require any significant effort on our side - neither in RI nor in TCK (unlike some other recent proposals).


> Cheers, Sergey
>> Thanks,
>> Marek