[jax-rs-spec users] [jsr339-experts] Re: Matching Algorithm in Spec

From: Sergey Beryozkin <>
Date: Wed, 15 Feb 2012 10:49:24 +0000

On 13/02/12 13:46, 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?

m2() : where is the ambiguity ? m2() has a clear priority, meaning it
needs to be checked first and its media type will intersect OK with
Accept and m1() needs to be discarded.

The question is which method needs to be checked first in this case:

     @GET @Produces("text/*") m1() { ... }
     @GET @Produces({"application/xml", "foo/*"}) m2() { ... }

and similarly for methods which may have @Consumes.

I'd suggest to clarify that when we have multiple methods with same HTTP
verb then the one which has more non-wildcard values needs to be tried
first during either Accept-_at_Oroduces or Content-Type-_at_Consumes
intersections. Your example will be as well the one I added above would
be 'taken care of' by this clarification.

> (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?

I actually see this one be more unpredictable, but I do not see anything
ambiguous in the above JAX-RS example. As far as the client is
concerned, it is fine with either type, As far as the JAX-RS code is
concerned, the m2() needs to be checked first because it specifies a
more specific media type. Thus application/xml needs to be returned/


> 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]

Sergey Beryozkin
Talend Community Coders