On Sep 6, 2012, at 10:09 AM, Marek Potociar wrote:
> First of all, WebTarget.pathParam(s) are misleading method names, since the actual intended purpose of the methods was to resolve a template variable to a value. IOW the expected behavior is:
>
> client.target("{a}").path("{b}").queryParam("a", "{a}").pathParam("a", "x") --> "x/{b}?a=x"
The documentation of pathParam talks only about path parameters, I don't think it says you can do this. However, I kind of agree that it is useful for other params like query or matrix.
> In this case a few answers are possible for the internal state of the returned UriBuilder:
>
> URI template: "{a}/{b}", internal template values: N/A
> URI template: "{a}/{b}", internal template values: "a" -> "x"
> URI template: "x/{b}", internal template values: N/A
Yes, 3.
> So finally, here comes my proposal:
>
> remove WebTarget.pathParam(s) methods
> introduce new WebTarget.resolveTemplate(s) methods, including method versions that provide flag for "/" encoding in path
> introduce new UriBuilder.resolveTemplate(s) methods, including method versions that provide flag for "/" encoding in path
I'm not sure these names fit the fluent API. I think a more declarative (less imperative) name like "paramValue" would be more appropriate.
-- Santiago