Hi Santiago
This is what "where R match = R(Td)" is...
I got it :-).
Thanks, Sergey
On 27/04/15 15:29, Santiago Pericas-Geertsen wrote:
>
>> 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
>
--
Sergey Beryozkin
Talend Community Coders
http://coders.talend.com/
Blog: http://sberyozkin.blogspot.com