On Aug 15, 2008, at 6:27 PM, Reto Bachmann-Gmür wrote:
> Marc Hadley wrote:
>> On Aug 15, 2008, at 3:33 AM, Reto Bachmann-Gmür wrote:
>>> RFC 2616 defines the q-value as indicator of the relative
>>> quality, not just as mean to sort the request media-ranges. If
>>> jax-rs wants to fully support this, we must know about the
>>> relative quality of the representations that can be generated.
>>>
>>> The RFC say:
>>>> The example
>>>> Accept: audio/*; q=0.2, audio/basic
>>>> SHOULD be interpreted as "I prefer audio/basic, but send me
>>>> any audio
>>>> type if it is the best available after an 80% mark-down in
>>>> quality."
>>>
>>> The server obviously cannot fully satisfy this request, if it
>>> doesn't know if the audio/basic producer's quality is less than
>>> 80% inferior than the producer of audio/something-else.
>>>
>> An application is free to implement more sophisticated matching
>> rules, all the information is available. I think the simple
>> approach of just matching based on the Accept header q-values will
>> be fine for the majority of cases.
> The point is that the matching wouldn't be based on the
> interpretation of the q-value following RFC 2616 but simply using
> it for sorting the accept-preferences. By not offering full support
> by the jax-rs runtime, applications wanting to do so can no longer
> benefit from many features otherwise provided by the jax-rs
> implementation.
>
The runtime supports a very common matching approach, say the 80%
rule, but in no way restricts an application to that rule. It is
possible to apply an alternative based on specific *application*
semantics of an acceptable set of media types [*], which is what the
example about audio is: application semantics about relative audio
quality.
For example, the following resource method uses many of the JAX-RS
features and can support the audio quality semantics as it requires:
@Produces("audio/*")
@GET
public Response get(@Context HttpHeaders h) {
List<MediaType> ahs = h.getAcceptableMediaTypes();
// application-based behaviour for media type selection
MediaType bestType = selectBestAudio(ahs);
Audio a = getAudio();
return Response.ok(a, bestType).build();
}
Note that the runtime algorithm of ordering will not get in the way
in such circumstances and in no way does it appear that applications
are no longer benefiting from many features otherwise provided.
You can even do this (although i do not know why you would want to):
@Produces("audio/basic")
@GET
public Response getBasic(@Context HttpHeaders h) {
return get(h);
}
:-) i.e. what is returned in the Response always takes precedence.
Paul.
[*] what does the following mean in such circumstances?
Accept: audio/*; q=0.2, audio/basic, image/png;q=0.3
obviously the q parameter when comparing in this case makes no sense
in terms of audio quality when applied to the image.
>