Hi Santiago, All,
I'd like to briefly get back to this thread, see comments in the end of
the message
On 09/04/13 14:46, Sergey Beryozkin wrote:
> On 09/04/13 14:31, Santiago Pericas-Geertsen wrote:
>>
>> On Apr 9, 2013, at 6:05 AM, Sergey Beryozkin<sberyozkin_at_talend.com>
>> wrote:
>>
>>> On 08/04/13 17:06, Sergey Beryozkin wrote:
>>>> Hi Santiago, All,
>>>>
>>>> I have some difficult time reading the section 3.7.2, specifically, the
>>>> 3.7.2/3/b part, it starts from
>>>>
>>>> (1)
>>>>
>>>> "If after filtering the set M has more than one element, sort it in
>>>> descending order as follows. Let
>>>> a client media type be of the form n/m;q=v1 , a server media type be of
>>>> the form n/m;qs=v2 and
>>>> a combined media type of the form n/m;q=v1 ;qs=v2 ;d=v3 , where the
>>>> distance factor d is defined
>>>> below."
>>>>
>>>> and then it mentions, after specifying the terms:
>>>>
>>>> (2)
>>>>
>>>> "Given these definitions, we can now sort M in descending order
>>>> based on
>>>> ≥ as follows7 :
>>>> • Let t be the request content type and CM a resource method’s
>>>> @Consumes
>>>> set of server
>>>> media types, we use the media type max≥ {S(t, c) | (t, c) ∈ {t} × CM }
>>>> as primary key.
>>>> "
>>>>
>>>> Now, given that a 'qs' factor comes into consideration only when a
>>>> client Accept values are checked against @Produces values, why have we
>>>> defined a combined media type in (1) as having 'qs' and then presumably
>>>> using that combined media types in (2), when referring to @Consumes ?
>>>
>>> I think I understand why it is written this way, simply to have a
>>> uniform algorithm text working for both @Consumes and @Produces, with
>>> the Content-Type - @Consumes selection working with both 'q' and 'qs'
>>> set to 1.0 by default.
>>> My concern that some users may get an impression that for example
>>>
>>> Content-Type: text/xml;q=0.8
>>>
>>> can affect the selection of the underlying resource method which IMHO
>>> does not make sense, because if it will affect then the client must
>>> be knowing too much about the implementation details of the server.
>>>
>>> If you share this concern then I can create an ice-box issue to get
>>> some clarifications applied to the selection algo text in 3.7.2
>>
>> Implementations aren't required to implement the algorithm in the
>> same manner, they just need to produce the same results. I'm fine with
>> adding a sentence about quality factors in content types (a new JIRA),
>> but I think it's pretty obvious that's not the intended use of q.
Right, so 'q' is obviously not for the use with Content-Type.
Can you please confirm 'qs' is not for the use with @Consumes values ?
I'm seeing a test asserting that adding 'qs' to @Consumes values affects
the selection of the methods.
I think 'q' & 'qs' can work in tandem in order to 1) get the right
response type and 2) possibly affect the selection of the method
Using 'qs' in @Consumes simply as a means to get a method selected is
feasible but I wonder if it was actually intended (referring here to the
spec text)
Example:
Content-Type: text/plain
@Consumes("text/*") m1()
@Consumes("text/plain;qs=0.8") m2()
m1 wins apparently. In fact m2() can never even be selected if we take
into the consideration that 'q' is not supposed to be used with
Content-Type.
So, do we allow for the use of 'qs' on @Consumes. IMHO it has to be
defaulted to 1.0 no matter what custom values are, thoughts, comments ?
Thanks, Sergey