Re: JSR311: JAX-RS 2.0

From: Marc Hadley <Marc.Hadley_at_Sun.COM>
Date: Mon, 18 May 2009 10:43:08 -0400

On May 13, 2009, at 3:29 PM, Bill Burke wrote:
>> 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.
I'm open to that idea.

>> (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
> multipart.
Right, we've also done some work in Jersey on additional form support
that I think has turned out well.

>> (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.
That's the kind of thing I had in mind though not necessarily limited
to JAXB.

>> (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?
To be clear I wasn't suggesting we invent any new templating
technology, just provide some standard means to integrate with
existing technologies. You can already do this with
ServletRequest.getRequestDispatcher(...).forward(...) but I think we
can improve on the usability quite a bit with some specific JAX-RS APIs.

> Finally:
> How about
> (vi) Asynchronous HTTP Support
> We wrote very simple, but powerful, Async HTTP abstraction:
We did discuss this internally but thought we needed a fair bit more
R&D in the area first.