Draft of the JAX-RS 2.0 JSR

From: Marc Portier <>
Date: Thu, 18 Nov 2010 13:31:40 +0100

> Please let us know if you'd like to be listed as a supporter of this JSR.

I do.

> Section 2: Request
> 2.1 Please describe the proposed Specification:

I've just witnessed some previews of this @devoxx (thx Paul, looking
good), thought I drop in some immediate thoughts

Haven't considered if it should be in or out scope, open for discussion,
I dunno this groups ambition nor time-schedule

[client api]
> The most commonly requested feature for JAX-RS 2.0 is a client API: many

* Sounds like these higher-level clients might be not only request-scope
but kept live (caching) clients

* I also see an obvious relation to JSE here: this aligns with my
general concern that JaxRS should keep being implementable on JSE as a
whole. Let's not grow the habbit of depending on stuff we don't need.
(this relates even somewhat to Jerome's request for the open TCK,
obviously a position I'ld like to back)

* what about ?

* about the preview I've seen on the higher level API, one thing we
surely we need to be able to inject from outside are the actual
http-protocol end-points: if those change I will not want to be
recompining my jax-rs code. The @Path to external services should
therefor be resolved rather then explicit

I think some uri-resolver available on the Application could handle
that. Pretty much like in xml apps using a catalogue: translate one uri
into an effective one (for lesser surprise and readability I would
propose a new scheme "service:/name"to clearly show resolving will happen)

> Hypermedia is a very important feature of RESTful Web applications.

Got to love it

Things to address:
* translating local references to public references (mapped or tunneled
from other services)

This is specially true in combination with external template processors
as suggested in the MVC approach below:
See e.g.

> Model-View-Controller (MVC) is a common pattern in Web frameworks, where

Unsure here:

* With custom MessageBodyWriter this is already possible (see e.g. our
current solution in (the
actual view-processing is selected by 2 params: a name and a media-type)

* Also note that view-production doesn't need to be template based
(xml-pipelines come to mind, in fact anything that could be large enough
to be needing streaming, ...) we should be able to accomodate

* On the side: we should think carefully about crossing the border from
WebService to WebApplication as it opens a bigger can of worms:
skin-ability, dependencies on js and other libs that need to be
injected/downloaded from somewhere else... all needed stuff in
web-front-end dev.

* With some opinion on splitting front-end and service to me this would
make more sense in an environment that supports decent modularization.

> JAX-RS 1.1 has limited support for parameter validation. This JSR will
> make it possible to validate a set of parameters, such as form or query
> parameters, and to return a meaningful response in case validation
> fails. The primary API utilized for validation will be the Bean
> Validation API.

* Note that it also makes sense to be able to externialize this
validation config info towards (non java) clients: they could be doing
local validation + direct feedback avoid roundtrip

* and/or might be calling upon some validation-only? rather then do full
PUT/POST in a headless-ajax-call (per member, or for the full entity)

> JAX-RS 1.1 was defined before JSR-330 was specified and as a result does

Need to read up on jsr330, it does sound a bit as more tending towards a
bigger jee dependency, if not in theory at least in practice/common use
(which I think we should avoid, but hey)