Yes Bill, you are right. I mean especially, where @Path("{var}/{var}")
is needed in one @Path. Is there any usecase for it?
best regards
Stephan
Bill Burke schrieb:
> 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
>>
>