Re: JSR311: Client API

From: Paul Sandoz <Paul.Sandoz_at_Sun.COM>
Date: Thu, 06 Mar 2008 16:38:01 +0100

Jerome Louvel wrote:
> Considering the initial scope of the JSR and the fact that the EG is already
> behind schedule, I don't think it is reasonable to pursue such an effort for
> now.

Makes sense. I agree with Marc that it could be something to consider
for another revision rather than for this revision.

> What surprises me is that the client-side API proposed has nothing to do
> with annotations and don't even seem to reuse any artifact from the current
> API.

The following classes are used:

 From a design perspective it:

- follows the same ease of use pattern for building requests as on the
   server side for build responses; and

- uses the message body readers/writers with injectable configuration as
   can be done on the server side.

The main focus of the API is the uniform interface (it can be considered
a very simple wrapper over say HttpURLConnection or the Apache HTTP
client). I wanted to avoid the reliance on any specific code artifacts
specifying, or partially specifying, a service that introduces static
dependencies in code thereby increasing the coupling between client and
server. From the way i approached the problem it did not make any sense
to reuse the annotations for the client side.

I also want a (pre-configured) client-side artifact i could inject and
reuse on the server-side, like as follows (without having to create or
depend on any server-specific code artifacts):

   public class Foo {
     @WebResourceRef("http://host/path") WebResource r;

     @GET public String get() {
       return r.get(String.class);


> What is the point? If we have to do something within JAX-RS (now or later),
> it would make much more sense to follow the approach proposed by Bill.
> Best regards,
> Jerome Louvel
> --
> Noelios Consulting
>> -----Message d'origine-----
>> De : Bill Burke []
>> Envoyé : mercredi 5 mars 2008 21:09
>> À :
>> Objet : Re: JSR311: Client API
>> Marc Hadley wrote:
>>> Issue 22[1] raises the question about whether we should
>> define a client
>>> API as part of JAX-RS. Back in October[2] we tabled
>> discussion until
>>> we'd made some progress on a client API we were developing
>> for testing
>>> purposes. Paul recently blogged about the resulting API
>> that has been
>>> developed in Jersey[3] and I'd like to revive the
>> discussion on issue 22
>>> now we have something concrete to propose. For reference I've also
>>> uploaded the javadoc[4] to the jsr311 project.
>>> The API is implemented in Jersey trunk and will be included
>> in Friday's
>>> release of the 0.6 snapshot. I'd recommend getting a copy
>> and playing
>>> with the classes a little to get a feel for how things slot
>> together.
>>> Paul will follow up tomorrow with some additional worked examples.
>>> Note that a client API was not one of our original
>> deliverables and is
>>> only being discussed in light of requests from EG members. It would
>>> still be an acceptable outcome (for me at least) to defer
>> inclusion of a
>>> client API to a subsequent revision of the specification.
>> I'm happy with Apache HttpClient and use it to test our jax-rs
>> implementation. Its a little clunkier than what you're
>> proposing, but a
>> bit more mature and much more feature rich.
>> For a client API I was thinking more of:
>> Where you could re-use jax-rs annotations and providers on an
>> interface
>> to create a proxy. What we have implemented still needs some
>> work, but
>> you probably get the gist.
>> Bill
>> --
>> Bill Burke
>> JBoss, a division of Red Hat
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail:
>> For additional commands, e-mail:
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

| ? + ? = To question
    Paul Sandoz