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:
http://wiki.jboss.org/wiki/Wiki.jsp?page=RESTeasyClientFramework
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
http://bill.burkecentral.com