Will JAX-WS Become the Primary Mechanism for Invoking RESTful Services?

Developers working with REST and XML/HTTP services have traditionally used light-weight APIs, such as java.net classes or Apache HttpClient. Web services APIs provided by JAX-RPC were SOAP and “enterprise” only and they required J2EE libraries. The situation changed with the release of JAX-WS and its inclusion into Java SE 6. JAX-WS supports RESTful services; also, its Dispatch interface allows clients to work with XML directly as opposed to having to use object mapping or completely unwieldy SAAJ API. A nice example of using JAX-WS to implement a client for a RESTful service is available in Mark Hadley’s blog.

However, I don’t think that JAX-WS is going to become the primary way of implementing RESTful clients just yet. In many situations, HttpClient provides more flexibility and control over HTTP calls.

For example, it is very straightforward to turn on basic authentication for a client using HttpClient APIs:

 HttpState httpState =httpClient.getState();
 httpState.setCredentials( AuthScope.ANY, 
     new UsernamePasswordCredentials(username, password));
 // Set the authentication header on the first request, don't wait for 401
 httpClient.getParams().setAuthenticationPreemptive(true);
        
 postMethod.setDoAuthentication(true);

Implementing the same requirement in JAX-WS is not a big deal either:

Map requestContext = dispatcher.getRequestContext();
requestContext.put(BindingProvider.USERNAME_PROPERTY, username); 
requestContext.put(BindingProvider.PASSWORD_PROPERTY, password);

However, it is not clear how to tell the client to set basic authentication header on the very request in case of the service does not issue 401 basic authentication challenge (which is pretty common). It is also not clear if there is a way to change authentication scheme (say, to digest) or authentication scope.

There are also other examples that demonstrate that in attempt to abstract the details of the transport protocol JAX-WS limits capabilities of the clients.

However, using JAX-WS REST capabilities still makes sense for applications that use both SOAP and RESTfull services. This allows developers to use consistent API for both types of services. Also, in some instances, a service provider may initially implement a service using XML/HTTP and later decide to switch to SOAP, say, to be able to use some of the WS-* specifications (this is actually a fairly common situation within an enterprise). In this case, using JAX-WS will certainly make the transition easier for the clients.