RESTful architecture and JAX-RS lead to distributed architectures. Roy Fielding's dissertation talks about a layered, client-server architecture. The JAX-RS Spec provides a great way to develop the server-side components, but doesn't describe how to develop the client-side components needed for a layered architecture. Note, I'm not talking about the browser as a client; rather, I'm describing Java-to-Remote-Resource communication. JAX-RS doesn't specify how a client API should be built. However, the various JAX-RS implementations does provide a client API. The client also seems to be the #1 requested feature for the next JAX-RS spec.

Before I get into the specifics of each client, I'll take the liberty to categorize different types/levels of RESTful clients I've seen that come bundled with JAX-RS projects:

• Raw Data Communication - There are existing client APIs such as java.net.URL and URLConnection and the more versatile HTTPClient. The java.net infrastructure allows you to make connections and get/post data. HTTPClient is more powerful than URLConnection, and provides lots of ways to manage the communication process but doesn't address how you should interpret the results of a GET into a Java object or convert a Java object into data for a POST.

• DTO Binding - You usually need a Java Object to encapsulate the raw data of RESTful communication. In a browser, you can easily convert JSon text into a JavaScript object using "eval()." RESTful Java clients can do something similar by using a Representation to Object transformation framework, such as JAXB2 -- which is favored by JAX-RS. If you're already using JAXB2 to provide a service (object-to-representation), you might as well re-use JAXB2 on the client side; that allows for seamless client-to-server communication, at least from a development standpoint. Write your transformation objecct once, use everywhere.

  Theoretically, clients with JAXB2 can be used to read data from any RESTful service. Write your service in Rails, Grails, or DJango and use that service with a "JAX-RS" client.

• Service Proxy - JAX-RS provides a nice abstraction on how you map a URL to a service layer method and of course how you transform XML into an object (and vice versa). Some JAX-RS clients promote creating a Java interface on which you put your JAX-RS annotations. Those JAX-RS implementations then allow you to create a proxy to the remote services using that same Java interface coupled with a root URL. Those client proxies reduce boiler plate code considerably.

  Theoretically, the service proxy approach can be flexible enough to perform a whole bunch of custom modifications to the communication process to perform "cross-cutting" functionality like security management and custom business logic related to the communication. One of my favorite custom cross-cutting business logic scenarios is "time-machine functionality" which involves adding some common URL parameters (&date=...). Additionally, this approach can theoretically be used when communicating with non-JAX-RS implemented services (Rails...).

This entry is part of my ongoing comparisons of JAX-RS frameworks. My next entry will include snippets collected from blogs and sample applications on how each of the four JAX-RS frameworks implements much needed RESTful client. I'll throw in some implementations of URLConnection and HTTPClient code as well.

From New York Java Consultant