Not long ago I worked on a team charged with building up a Java-based REST infrastructure. Our goals were to first support what was then an emerging specification for Java-based RESTful services called JAX-RS. Beyond that, we had thoughts of building an entire framework, both server and client, around RESTful services written in Java. Some of the people I worked with on that team are now part of the team that is responsible for an open source implementation called Apache Wink which embodies some of our early ideas and much more.

Developers have been implementing RESTful services in Java for a long, long time, so what's the deal with JAX-RS and an entire framework? Well, the way developers have been implementing REST services typically involves writing their own custom servlet. Within the servlet they write custom code to route incoming requests to the proper back-end resources. This can be extremely simple, but it can also become quite involved depending on the number of resources, the degree to which they are nested, depend on content negotiation capabilities, and more. Why not turn a lot of this over to a container capable of providing such function?

A JAX-RS aware container can provide a lot of the function that developers previously had to code in their servlets. In such a container users can package and deploy a Java bean with annotations that declare a resource and describe that resource to the container. For example, consider the following bean that represents book orders:

package jaxrs.example

@Path("/bookorders")
public class BookOrders {

     @GET
     @Path("/{orderId}")
     @Produces("application/json")
     public BookOrder getBookOrder(
@PathParam("orderId") String orderId) {
            ....
     }

     @POST
     @Accepts("application/json")
     public void createBookOrder
(BookOrder newOrder) {
            ....
     }

This is a very simple example, but in just this little bit of code with annotations, quite a bit of logic that would have gone in a servlet is replaced. The annotations in this example encapsulate both request routing and content negotiation. For instance, an incoming HTTP GET request with a path like "/bookorders/{orderId}" would automatically be routed to the BookOrder's getBookOrder method provided the HTTP Accept header in the request was congruent with the "application/json" content type. Likewise, an incoming HTTP POST request with a path of "/bookorders" would be routed to the BookOrder's createBookOrder method providing the Content-Type of the incoming request was "application/json". As you can see, both request routing and content negotiation capabilities are provided by annotation metadata.

Use cases with JAX-RS can be much more complex. Users can develop deeply nested resource URI trees, plug into the data handling framework for both requests and responses, and much more. Many of the things that users require to provide Java-based RESTful services are either provided by JAX-RS or can be supplied by the user via standards-based extension mechanisms.

However, and perhaps you picked up on this above, the JAX-RS specification only provides standards for the server-side programming model. A standard client-side programming model API for Java-based RESTful services is not in the scope of this specification (or any other one that I'm aware of at this time, but please drop me a line if you know of one). The Apache Wink project (and many other Java-based RESTful services offerings to be fair) realizes that such an API and framework provides quite a bit of convenience to developers. Instead of the developer implementing such a framework on their own, or worse yet, having to deal with low-level client-side HTTP APIs (i.e. Jakarta Commons Http Client), they can simply utilize a higher level API to communicate with resources they declared on the server using JAX-RS. For example, using the Apache Wink project, our client to the BookOrders resource may look like the following:

RestClient client = new RestClient();

Resource resource = client.resource
("http://jaxrs.example.com/bookorders/1");
BookOrder bookOrder = resource.accept
("application/json").get(BookOrder.class);

It certainly seems like the movement toward RESTful services is a growing trend. Many cloud service providers, Amazon most notably, offer REST interfaces to the functions and capabilities they deliver. In addition, many vendors now deliver products with REST interfaces to accompany the more traditional GUI and CLI interfaces. As the use of REST continues to grow, it seems inevitable that the use of Java with such services, on both the client and server, will grow as well. If you have any interest in this area, I'd encourage you to take a look at the different Java offerings available for building RESTful services and clients. With admitted bias I would suggest starting with the Apache Wink project. Download the code, try out the samples, and get involved in the open community.