Well (I) is ambiguous even with the wildcard, IMO. (II) is covered by
the spec no? text/plain would be chosen. I don't really care what
rules you add, but it does bother me when people write application code
like this. Why? Well, clients should be written within the constraints
of HTTP, not JAX-RS. If a client does:
Accept: text/plain, application/xml
It should expect either back.
On 2/13/12 2:25 PM, Santiago Pericas-Geertsen wrote:
>
> On Feb 13, 2012, at 10:18 AM, Bill Burke wrote:
>
>> IMO, the ambiguity should be left in. Why? Because the app developer shouldn't be writing interfaces that are ambiguous in the first place.
>
> What about cases (I) and (II) below? Would you consider those ambiguous as well? In some cases, ambiguity depends on which Accept you get in the request; in others it can be determined statically.
>
> -- Santiago
>
>>
>> On 2/13/12 8:46 AM, Santiago Pericas-Geertsen wrote:
>>> Hello Experts,
>>>
>>> When adding support for qs during matching (already in EDR2), I realized that step 3b in Section 3.7.2 is a bit vague (underspecified). After a few iterations, I came across a more precise (and more complex) description of this step. The original text handles the case of compatible types like:
>>>
>>> text/plain> text/*> */*
>>>
>>> quite well, but it's not precise when comparing incompatible types like:
>>>
>>> text/* ? application/xml
>>>
>>> Here a few interesting cases:
>>>
>>> (I) Request (Accept: text/plain, application/xml)
>>>
>>> Resource {
>>> @GET @Produces("text/*") m1() { ... }
>>> @GET @Produces("application/xml") m2() { ... }
>>> }
>>>
>>> Which method should be matched in this case?
>>>
>>> (II) Same as (I) but with q=0.8 in Accept:
>>>
>>> Request (Accept: text/plain, application/xml;q=0.8)
>>>
>>> What about in this case?
>>>
>>> There are some other cases that are similar to these. In addition, there cases in which matching is clearly ambiguous for which the old algorithm was completely silent. The new one suggests that implementations issue a warning in these cases.
>>>
>>> Place take a look at the re-written step in [1] and provide feedback.
>>>
>>> -- Santiago
>>>
>>> [1] http://java.net/projects/jax-rs-spec/sources/git/content/spec/spec.pdf?rev=39d35e0fbf5949ba751a40b999900a4ed804852e
>>
>> --
>> Bill Burke
>> JBoss, a division of Red Hat
>> http://bill.burkecentral.com
>
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com