> 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
http://hc.apache.org/ ?
* 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]
> 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.
http://docs.outerthought.org/kauri-docs-current/195-kauri/g2/264-kauri.html#publicUri
>
> 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
http://docs.outerthought.org/kauri-docs-current/206-kauri.html (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)
regards,
-marc=