users@jersey.java.net

Re: [Jersey] Server prioritization of media types

From: James Strachan <james.strachan_at_gmail.com>
Date: Fri, 18 Dec 2009 14:21:52 +0000

Letting the server specify it is always going to return html before
xml sounds like a good thing; I agree the qs thing is maybe a bit
hacky as a client could use weird numbers etc.

The only other thought I have right now is, I generally dislike
annotations with arrays in them; as you can't use constants (probably
due to arrays not being immutable). The various produces/consumes
annotations can often end up being not very DRY as you have to cut n
paste the usual suspects of MIME types all over the place. So I'd like
to be able to use a single String parameter for @Produces, @Consumes,
@ImplicitProduces, @ProducesOrder - so folks can use a couple of
constant String values across all their code (as there's likely to be
only a fairly small set of values of these things in any app).


2009/12/18 Paul Sandoz <Paul.Sandoz_at_sun.com>:
> 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
>
>



-- 
James
-------
http://macstrac.blogspot.com/
Open Source Integration
http://fusesource.com/