Hi,
Some initial work has been done for CXF JAXRS have its own Client API.
The code is at [1].
Some of the design goals were to come up with at least something
different compared to what other JAXRS implementations have
(Jersey and RestEasy), reuse the existing JAXRS classes and approaches
(use of providers), ensure JAXWS users can start playing fast.
I've already done some overview at [2].
In short we've tried to do 3 forms of client api for a start.
Proxy-based, http-centric and xml-centric.
Proxy based api is about people being able to reuse what they've already
done on the server side. Root and sub-resource classes can be reused
on a client side as proxies, irrespectively of whether they derive the
metadata from interfaces or classes. Currently it's not possible to have
@Context
parameters in resource method signatures, but I'm realizing while typing
this text that they actually have to simply ignored on the client side.
This style will also encourage users returning annotated interfaces or
concrete classes in sub-resource locators.
Proxies can be controlled as http-centric clients, except that they
can't explicitly do post()/get() or control the way URI gets built. I
thought it would make things a bit 'chaotic'
if we allowed to do it, if one works with the interface/class then the
methods is what drives the way URI gets built and how invocations are
made.
Every proxy is a Client [3] so one can customize the request headers or
check the actual HTTP (JAXRS) Response. One can easily switch to
WebClient while preserving the existing proxy settings and back from
WebClients to proxies. This might be of interest when working with a set
of services, when interfaces are available for only some of them, when
investigating at runtime the possibly unexpected proxy response, etc,
etc.
HTTP-centric api is really about doing HTTP programming [3]. Every
WebClient is a Client. Users can deal with Response or typed object
responses. There're some utility methods there for a client to navigate
back and forward. You'll likely find quite a bit of similarity here with
how say Jersey does the client API - but I can assure you it's really a
basic common thing to do, things like WebClient.get(T class) for
example, or WebClient.form(new Form()). For example, I've started with
WebClient.form(MultivaluedMap) but having a little wrapper on top of
MultivaluedMap is an obvious thing to do.
Finally, we have xml-centric API (nearly non-existent at the moment).
It's a subset of http-centric one. One can obviously do
StreamSource source = new
WebClient("http://bar";).get(StreamSource.class)
and proceed from there. But we'll enhance the XMLSource utility class to
highlight the fact that this form of dealing with XML responses is
probably the most flexible and robust one.
I'd welcome a lot any constructive feedback. There's actually quite a
bit work which still needs to be done (chains, spring injection, etc).
But what we already have will make it into CXF 2.2 so we'd like to do it
as right as possible. Any ideas on what is missing, what may need to be
added or changed will be welcome - please send your feedback to cxf
lists or contact me directly. If someone could give it a try with the
latest CXF trunk and see how natural the client api fits into a specific
task then it would be cool...
Cheers, Sergey
[1]
https://svn.apache.org/repos/asf/cxf/trunk/rt/frontend/jaxrs/src/main/ja
va/org/apache/cxf/jaxrs/client
[2]
http://sberyozkin.blogspot.com/2009/02/cxf-jaxrs-client-api-preview.html
[3]
https://svn.apache.org/repos/asf/cxf/trunk/rt/frontend/jaxrs/src/main/ja
va/org/apache/cxf/jaxrs/client/Client.java
[4]
https://svn.apache.org/repos/asf/cxf/trunk/rt/frontend/jaxrs/src/main/ja
va/org/apache/cxf/jaxrs/client/WebClient.java
[5]
https://svn.apache.org/repos/asf/cxf/trunk/rt/frontend/jaxrs/src/main/ja
va/org/apache/cxf/jaxrs/client/XMLSource.java
