users@jsr311.java.net

Re: When to sort Accept header values

From: Sergey Beryozkin <sberyoz_at_progress.com>
Date: Thu, 29 Jan 2009 11:29:30 -0000

Hi Marc


See my comments with S.B please
>
> I’d like to clarify when to sort Accept header values.
> Consider this example.
>
> public class TestClass {
>
> @Produces(“application/xml”)
> public Book getBook1() {}
>
> @Produces(“application/json”)
> public Book getBook2() {}
>
> }

>
> 2.Accept: application/xml, application/json
>
> getBook1() is selected ?
>
> 3.Accept: application/json, application/xml
>
> getBook2() is selected ?
>
The spec doesn't define which one is chosen, sorting is only specified
for specificity (x/y > x/* > */*) and q value.

S.B. So would it not make sense to take an original order of Accept header values into consideration when all the media types
(those in Accept and Produces) have the same( or default 1.0 quality factor) ? It will make example 2/4 above work as intuitively
expected, without users having to add quality factors to Accept ?

> if the above examples are correct then is it the case that Accept header values should not be sorted for the purpose of selecting
> a method to be invoked ?
>
> I’ve got a bit confused – when they actually should be sorted ? Section 3.7.2/3.b mentions Accept, but say nothing about sorting
> of accept values. Which makes sense,
>
> Do they need to be sorted only when a selected method has multiple Produces values, to determine the media type of a given
> response ?
>
The sorting for selecting a method in 3.7.2 step 3 applies regardless
of whether the @Produce/_at_Consumes is singular or multiple valued.

S.B. - but this sorting applies to @Produce/_at_Consumes values available on different matching methods

The sorting to select a type in 3.8 only applies when the chosen method
can produce more than one media type.

S.B. This applies to the intersection of Accept and a given @Produces' values (3.8.5, 3.8.7) ?
I guess the answer to my (subject) question is that the spec does not require Accept values be sorted

Thanks, Sergey

Marc.

---
Marc Hadley <marc.hadley at sun.com>
CTO Office, Sun Microsystems.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe_at_jsr311.dev.java.net
For additional commands, e-mail: users-help_at_jsr311.dev.java.net