Hi all,
does anyone knows a usecase where it is useful to require
@Path("{var}/{var}"), with respect to the resource oriented architecture?
As Paul said, IMO everytime @Path("{varA}/{varB}") would work.
If there is no usecase, let forbid it. Or at least let recommend to not
use it and accept unexpected behaviours, if not both {var}s matches the
same value.
Than we have no problems with {"1", "3/4"} or {"1", "3", "4"}.
best regards
Stephan
Paul Sandoz schrieb:
> 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.
>