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

From: Santiago Pericas-Geertsen <>
Date: Fri, 9 Mar 2012 08:53:25 -0500

Hi Sergey,

> I admit I'll have to read few more times, it reads like a complex theorem proof at the moment for me :-).

 Yes, I think it takes a couple of reads to get the idea.

>>>> 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
> Is it about dealing with cases like this one ?
> If yes, then do you really think it is important to add some precision in matching two types like text/* & application/xml ?
> As I said I'm still trying to grasp what I've read, so please tell me, would the updated text make it feasible for
> text/* & application/xml be matched ?

 It would basically cover the otherwise ambiguous cases below:

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

 It does not in any way complicate the algorithm implementation (it obviously doesn't need to follow the formalization in the spec). It does, however, resolve a number of ambiguous cases involving _incompatible_ types that do not follow the simple m/n > m/* > */* rule (for a fixed m and n).

-- Santiago