Well, I see the following example alot. Especially for sub-resources
fronting a DB that are reused.
@Path("/")
public class Foo
{
@Path("{var}")
public Sub get() {}
}
public class Sub
{
@Path("{var}")
@GET
public String get() {}
}
Stephan Koops wrote:
> 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.
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe_at_jsr311.dev.java.net
> For additional commands, e-mail: users-help_at_jsr311.dev.java.net
>
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com