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
>>
>