I tweeted a while ago during a moment of frustration getting implicit
views to work with a resource bean that also returned XML & JSON
http://twitter.com/jstrachan/statuses/1120925036
which led to Paul kindly responding to me which led to a bit of a long
conversation which we thought was better we brought over here to see
what others thought.
So here's a quick summary of a rather long conversation...
I kinda touched on the issue in my rather long rambling blog post
http://macstrac.blogspot.com/2009/01/jax-rs-as-one-web-framework-to-rule.html
and raised an issue around this area...
https://jersey.dev.java.net/issues/show_bug.cgi?id=187
Basically the issue boils down to the JAX-RS specification favouring
more specific paths to implicit or regex ones and there being no way
to prefer one representation over another on the server side; if you
have implicit views or explicit views defined like this...
@GET
@Path("{view}")
@Produces({MediaType.TEXT_HTML})
public Viewable genericView(@PathParam("view") String view) {
return new Viewable(view, this);
}
and some XML/JSON methods such as this on the same resource...
@GET
@Path("foo")
@Produces({"text/xml", "application/xml", "application/json"})
public SomeDTO getSomeDTO() {
...
}
then typically you'll want your web application to return HTML by
default unless XML/JSON is the only option preferred - whereas the
exact opposite happens; XML/JSON is usually always returned to web
browsers.
Its even worse with Apple's Safari which has an accept header of this...
text/xml,application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,image/png,*/*;q=0.5
which tends to favour text/xml anyway (despite it only rendering XML
as plain text! :).
So there's a need to be able to annotate a resource to kinda say 'use
implicit views for this resource in priority to other representations'
to be able to do what most web framework users would expect (returning
HTML by default to web browsers).
Paul suggested we use an annotation like
@ImplicitProvides("text/html") so we can annotate explicitly that
implicit views be used and to use them in preference to other
representations if there is a wide ranging accept header (such as for
web browsers). Being able to specify qualities on MIME types can also
help this...
https://jsr311.dev.java.net/issues/show_bug.cgi?id=65
https://jsr311.dev.java.net/issues/show_bug.cgi?id=46
The aim of this is to let Jersey with implicit/explicit views behave
kinda like a normal web framework, unless folks ask for only a
specific kind of representation (say XML or JSON). As a small stepping
stone I've submitted a couple of patches to the bookstore application
to show how such a HTML + XML/JSON application could look with
implicit views...
https://jersey.dev.java.net/issues/show_bug.cgi?id=189
https://jersey.dev.java.net/issues/show_bug.cgi?id=190
(the tests fail currently as it returns XML instead of HTML to
demonstrate the issue we're trying to solve :)
Paul's been looking at a way to implement @ImplicitProduces in a
simple way to do accept filter modification in lieu of more wider
ranging changes to the JAX-RS specification to support the
mimeType;q=someNumber type notation on media types to denote
priority/quality and using that to sort the possible representations
that can be returned from a JAX-RS request ahead of the current rules
of the path length etc.
I think that gives a rough overview; Paul did I miss anything (other
than lots of rambling from me :)?
Anyone else hit similar issues or have any further thoughts on this?
--
James
-------
http://macstrac.blogspot.com/
Open Source Integration
http://fusesource.com/