Facilitating the Spread of Knowledge and Innovation in Professional Software Development

Write for InfoQ


Choose your language

InfoQ Homepage News Work begins on JAX-RS 2.0

Work begins on JAX-RS 2.0

Leia em Português

This item in japanese

Over the years the adoption of REST as an integration architecture outside of the Web has grown, so it was inevitable that Java and Java EE would be graced with a suitable standard, which was JSR 311, or more often called JAX-RS. This was finalised in 2008 and became part of EE6. Now over that time there have been several implementations, including the mandatory reference implementation. Many Java developers have found JAX-RS a benefit, though of course there have been the inevitable discussions about whether or not JAX-RS is RESTful.

However, as with most good standards, implementation experience is now being fed back into JAX-RS, with Roberto Chinnici of Oracle (ex Sun), recently announcing ...

Below you'll find a draft of the JAX-RS 2.0 JSR. Since JAX-RS 1.1 closed, we've been interacting with many of you in the community, at conferences and across various forums, so hopefully you won't find any surprising items in this draft. Please send us your comments/suggestions in the next couple of weeks. In parallel, we'll be working on filling in the remaining sections marked as TBD, including the schedule and business terms. We'd like to submit the JSR in early December, so as to get it approved by the JCP Executive Committee ahead of the year-end holidays.

Some highlights from the proposals include:

  • The most commonly requested feature for JAX-RS 2.0 is a client API: many if not all JAX-RS implementations provide some degree of client API support. This JSR will define two client APIs, both compatible with the REST style: a low level API using a builder pattern and a higher level one leveraging the former.
  • Model-View-Controller (MVC) is a common pattern in Web frameworks, where it is used predominantly by HTML-based applications. Adopting the MVC terminology, JAX-RS resource classes are comparable to controllers. This JSR will specify an MVC architecture compatible with the JAX-RS programing model. Java Server Pages will be specified as one type of view. It will be possible to plug in other view technologies, for example FreeMarker or StringTemplate.
  • JAX-RS 1.1 was defined before JSR-330 was specified and as a result does not utilize 330 annotations, such as @Inject, as effectively as it could. This JSR will specify closer integration with 330 annotations that may potentially render some existing annotations in JAX-RS, such as @Context, deprecated or redundant.
  • JAX-RS 1.1 defines a synchronous request response model on the server side. This JSR will specify a simple asynchronous request processing model such that a response can be returned asynchronous to the request. Servlet 3.0 can be leveraged to enable such support but implementations may choose to use other container-specific APIs instead.

Stefan Tilkov, has announced support of the new proposal, and Jerome Louvel, lead developer of the Restlet framework, is also supportive, but raises concerns about the TCK:

My main concern is about TCK access for open source projects such as the Restlet Framework ( Despite several requests (including via the JCP scholarship program), we never got access to the TCK. Could you make clear upfront what will be the business/license terms for implementations of JAX-RS 2.0 distributed under open source licenses?

Bill de hÓra, one of the members of the original expert group, is also in agreement and provides the most feedback so far, including:

One practical problem I've seen is that real world systems don't always return errors in the same format as requested by the client (assuming the app developer requested anything at all, again common). Simple example - tomcat/jetty throwing up html error pages. We can argue this is quality problem with the server but it's ugly on clients when it happens and the entity binding blows up. I'd like to see something that echoes the exception mapper on the server side of JAX-RS. Another possibility is allocating handlers onto response codes.

Roberto asks for comments and suggestions relatively soon because, as he says "We'd like to submit the JSR in early December, so as to get it approved by the JCP Executive Committee ahead of the year-end holidays." So are there other things that need considering in JAX-RS 2.0?

Rate this Article