jsr370-experts@jax-rs-spec.java.net

Re: [jax-rs-spec users] SubResource method vs SubResource locator clarification

From: Santiago Pericas-Geertsen <Santiago.PericasGeertsen_at_oracle.com>
Date: Mon, 27 Apr 2015 10:29:23 -0400

> 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