IMO, the ambiguity should be left in. Why? Because the app developer
shouldn't be writing interfaces that are ambiguous in the first place.
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