Re: JSR311: JAX-RS 2.0

From: Bill Burke <>
Date: Wed, 13 May 2009 15:29:51 -0400

Marc Hadley wrote:
> Experts,
> We are starting to think about what we'd like to include in a new JSR
> for a major revision to JAX-RS. Below are the items we have so far,
> please let us know if there are items you'd like to add/remove/change.
> Thanks,
> Marc.
> (i) Client API
> This has been the most frequent RFE. We can re-use a number of current
> APIs, most notably message body readers and writers but will require
> several new APIs too. Most JAX-RS implementations provide a client API,
> we will request and survey submissions to decide on the best approach.

The proxy-based approach that RESTEasy has done is *VERY POPULAR*.

IMO, we need both: he proxy approach and a Apache HTTP Client-like api.

> (ii) Quality of source
> Currently all server-provided representations are assumed to be of equal
> quality for the purposes of content negotiation. We will add the ability
> to specify a relative quality factor for each available representation
> format.
> (iii) Form data and multipart handling
> Improve the handling of form data and MIME multipart data

I tried to get better form support, but you guys shot me down on this
earlier. We implemented this in Resteasy:

RESTEasy has a number of ease of use APIs and Readers/Writers around

> (iv) Declarative linking
> Use of annotations to automate link creation.

I think we can have a few embeddable link classes that can be embedded
within JAXB structures.

> (v) Templating/MVC
> Production of representations using standard template technologies (e.g.
> JSP).

I know you guys (Jersey) have some stuff around this. Resteasy did some
integration with Spring's ModelAndView objects. The Seam team did some
Resteasy integration around their equivalent as well. There's probably
something standard we can define here.

BUT...I'm not sure this should be the domain of JAX-RS as this is more
of a Web-Framework like feature. Maybe JAX-RS should focus on tighter
integration with JSF/Web Beans instead?


How about

(vi) Asynchronous HTTP Support

We wrote very simple, but powerful, Async HTTP abstraction:

Bill Burke
JBoss, a division of Red Hat