On 17/05/13 15:32, Bill Burke wrote:
>
>
> On 5/17/2013 9:40 AM, Sergey Beryozkin wrote:
>> Hi Bill,
>> On 17/05/13 14:35, Sergey Beryozkin wrote:
>>> On 17/05/13 13:59, Bill Burke wrote:
>>>>
>>>>
>>>> On 5/17/2013 4:35 AM, Sergey Beryozkin wrote:
>>>>> Hi Bill
>>>>> On 17/05/13 04:41, Bill Burke wrote:
>>>>>> Let me give you an example:
>>>>>>
>>>>>> Given this request:
>>>>>>
>>>>>> OPTIONS /sub
>>>>>>
>>>>>> This will match:
>>>>>>
>>>>>> @Path("/")
>>>>>> class Resource {
>>>>>>
>>>>>> @Path("{id}")
>>>>>> public Locator locator() { return new Locator();}
>>>>>>
>>>>>> }
>>>>>>
>>>>>> class Locator {
>>>>>>
>>>>>> @OPTIONS
>>>>>> public String options() { return "OK"; }
>>>>>> }
>>>>>>
>>>>>> But this won't match:
>>>>>>
>>>>>> @Path("/")
>>>>>> class Resource {
>>>>>>
>>>>>> @GET
>>>>>> @Path("sub")
>>>>>> public String get() { return "OK"; }
>>>>>>
>>>>>> @Path("{id}")
>>>>>> public Locator locator() { return new Locator();}
>>>>>>
>>>>>> }
>>>>>>
>>>>> Seems to me it will too. @GET method is selected only if no
>>>>> @OPTIONS is
>>>>> available and in this case it is available.
>>>>>
>>>>
>>>> Check out the spec. It won't match because "sub" is matched in 2(h).
>>>> 2(h) says that if there are any non-locator matches, then go to 3, then
>>>> 3(a) will abort the request.
>>> But get() does not match OPTIONS, it will only match
>>>
>>> GET /sub
>>>
>>> and it will only match OPTIONS if no OPTIONS handler is available, but
>>> OPTIONS handler is available.
>>>
>>> Now we go to Locator and then we match OPTIONS. The only issue is that
>>> what happens if Locator has no OPTIONS too, I guess we have missed then
>>> the opportunity to match Resource.get because GET can be used to match
>>> OPTIONS if no OPTIONS exist. To be honest I do not see it as a big
>>> issue,
>>>
>>> I believe the spec says that if no OPTIONS handler is available then
>>> check GET, we have no GET on Locator so we should report all the verbs
>>> supported by it and its root Resource which is "GET", and it is cheaper
>>> than calling @GET method as a last resort as doing it may be expensive
>>>
>> Got confused here, this is a case of HEAD where GET may be called, did
>> you mean HEAD ? and if it is OPTIONS then Resource.get can not be
>> matched at all
>> \
>
> Again, go walk through the algorithm in the spec. The spec algorithm
> does not check which methods are available until step 3(a).
>
Well, both Resource methods are candidates, and those candidates which
are subresource locators lose to those which are not
Sergey