Because u may not know your subresource is being reuse. A subresource
may be from another project or even a third party. I just don't see a
problem with multi-varnames....
Replace {var} with {id} and Foo/Sub with Customer/Address and maybe u
see what i mean.
Bill
Stephan Koops wrote:
> Why not use
>
> @Path("/")
> public class Foo
> {
> @Path("{varA}")
> public Sub get() {}
> }
>
> public class Sub
> {
> @Path("{varB}")
> @GET
> public String get() {}
> }
>
> with different names (varA, varB) instead of the same in both cases?
>
> best regards
> Stephan
>
> Bill Burke schrieb:
>> 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
>>>
>>
>
> ---------------------------------------------------------------------
> 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