> On Apr 27, 2015, at 9:48 AM, Sergey Beryozkin <sberyozkin_at_talend.com> wrote:
>
> Hi Santiago
> On 27/04/15 14:21, Santiago Pericas-Geertsen wrote:
>> Hi Sergey,
>>
>>> POST /root/1
>>>
>>> @Path("root")
>>> public class Root1 {
>>> @GET @Path("1") Response get() {...}
>>> @Path("{id}") Root1Sub getSub() {...}
>>> }
>>>
>>> getSub() is discarded, we have 405.
>>>
>>> but with
>>>
>>> @Path("root")
>>> public class Root2 {
>>> @GET @Path("{id}") Response get() {...}
>>> @Path("1") Root2Sub getSub() {...}
>>> }
>>>
>>> getSub() is selected and is given a chance to check if it has a POST handler.
>>>
>>> I've just re-read 3.7.2.2, (g) and (h) in particular, and it appears that a sub-resource locator never gets a chance if there's a path match on one of the current resource's methods such as "get()".
>>
>> Why? Are you saying that in (g) the set M is not empty? I'm assuming you're talking about your second example above.
>>
> Yes, after Root2 is selected, we have "1" left, and that matches get() with a Path("{id}"). Right ?
No, let’s start from the beginning:
E = { R({id}), R(1) }
then after sorting you get,
R_match = R(1)
but then M is empty because there is no _sub-resource method_ whose path is R(1) (note that the set is defined on equality of expressions), because R(1) is decorating a _sub-resource locator_.
— Santiago