users@jersey.java.net

RE: [Jersey] Server prioritization of media types

From: Guba, Nicolai <nguba_at_bioware.com>
Date: Wed, 13 Jan 2010 07:40:16 -0800

Keep it simple :)

-- 
   =NPG=
-----Original Message-----
From: Paul.Sandoz_at_Sun.COM [mailto:Paul.Sandoz_at_Sun.COM] 
Sent: Friday, December 18, 2009 7:58 AM
To: users_at_jersey.dev.java.net
Subject: [Jersey] Server prioritization of media types
Hi,
Because clients can send different values for the Accept header and  
because the server wants return particular representations regardless  
of the priority set by the client there needs to be a way for the  
server to set priorities.
The best example is when a service wants to support HTML and XML and/ 
or JSON and always wants to return HTML to clients that accept HTML.
This has been implemented for @ImplicitView, for example:
   @ImplicitProduces("text/html;qs=5")
Which states multiply the "q" factor of any media type "text/html" in  
the accept header by 5 and use the result to order against other media  
types.
Having thought a little more i am wondering if the multiplying factory  
is really the right approach. Theoretically a client could send:
   text/xml, text/html;q=0.1
but the server may still want to send HTML. The client has no way of  
knowing what priorities the server is setting so cannot really adjust  
accordingly without reading some human documentation.
Perhaps we we require is inequalities relative to other media types  
that a resource is capable of producing. For example, that "text/html"  
 > "text/xml" regardless of the quality value set by the client.
A more concrete example is as follows:
   @ProducesOrder("text/html, application/html > text/xml, application/ 
xml > applicaiton/json")
   public class X {
     @GET
     @Produces({"application/xml", text/xml})
     public ... getXml() { ... }
     @GET
     @Produces({"application/json"})
     public ... getJson() { ... }
     @GET
     @Produces({"text/html", "application/html"})
     public Viewable getHtml() { ... }
   }
   @ProducesOrder("text/html, application/html > text/xml, application/ 
xml > applicaiton/json")
   @ImplicitProduces({"text/html", "application/html"})
   public class Y {
     @GET
     @Produces({"application/xml", text/xml})
     public ... getXml() { ... }
     @GET
     @Produces({"application/json"})
     public ... getJson() { ... }
   }
And it should also be possible to declare an application wide produces  
order, which if present would apply to all resources if a resource  
does not explicitly declare @ProducesOrder.
The above states that "text/html" and "application/html" have a higher  
order than "text/xml", "application/xml" and "application/json". Then,  
"text/xml" and "application/xml" have a higher order than "application/ 
json".
I suppose one could declare:
   @ProducesOrder(""text/html, application/html > */*")
to declare that text/html" and "application/html"  have a higher order  
than anything else.
The following using arrays may be preferable to reduce syntax errors:
   @ProducesOrder({{"text/html", "application/html"}, {"text/html",  
"application/html"}, {"applicaiton/json"}})
This is actually rather simple to implement because it requires basic  
manipulation of the Accept header.. where as the support for "qs" on  
produces requires a more complicated algorithm.
Thoughts?
Paul.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe_at_jersey.dev.java.net
For additional commands, e-mail: users-help_at_jersey.dev.java.net