Marc Hadley wrote:
> On May 21, 2008, at 12:03 PM, Paul Sandoz wrote:
>>> An oversight, for consistency I guess we should allow the collection
>>> types too. So given:
>>> @Path(value="{p}/foo/{p}", limited=false)
>>> @PathParam("p") List<String> paths
>>> GET /1/foo/3/4
>>> Should paths be:
>>> {"1", "3/4"}
>>> or
>>> {"1", "3", "4"}
>>> I think this should inform the decision we make re @PathParam("p")
>>> List<PathSegment> paths. I'd like some consistency with how the path
>>> is split up regardless of the type of list - i.e. I'd rather not
>>> special case PathSegment.
>>
>> It breaks the consistency with template creation and will result in an
>> error when using such matched values for URI creation from a URI
>> template. I think {p} MUST have the same value for matching and
>> creation. The workaround is trivial: use another template name for the
>> second one.
>>
> I'm conflicted on this one. I agree its odd and easily worked around but
> given that you can already do:
>
> @Path("{var}")
> public class RootResource {
>
> @Path("{var}")
> public SubResource locator(@PathParam("var") String var) {...}
> }
>
> and GET /1/2 will call locator("2") it doesn't seem much of a stretch to
> support:
>
> @Path("{var}")
> public class RootResource {
>
> @Path("{var}")
> public SubResource locator(@PathParam("var") List<String> vars) {...}
> }
>
> where GET /1/2 will call locator({"1","2"}). If that works then it would
> be surprising if
>
> @Path("{var}/{var}")
> public class RootResource {
>
> @GET
> public Result get(@PathParam("var") String var) {...}
> }
>
> didn't call get({"1","2"}).
>
I don't find it so surprising :-) The later is one URI template where as
the others are two separate URI templates that are matched separately.
When combining templates certain rules (specified the by the URI
template draft) come into force, as is the case when combining for URI
construction.
If I use the URI builder (or any other conforming URI template
implementation) to construct a URI from "{var}/{var}" then i can only
assign one value to "val".
So i guess it comes down to whether we want round trip consistency for
matching and construction.
Paul.
--
| ? + ? = To question
----------------\
Paul Sandoz
x38109
+33-4-76188109