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();
new UsernamePasswordCredentials(username, password));
// Set the authentication header on the first request, don't wait for 401
Implementing the same requirement in JAX-WS is not a big deal either:
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.
Have you looked at Jersey (http://jersey.dev.java.net)?
Thanks for the link, no, I did not know about JAX-RS. I hope that eventually JAX-WS and JAX-RS will be joined together to represent a uniformed way of implementing Web services. In the ideal world, APIs should not change much depending on how a service is implemented.
[…] In Java world, SOAP was promoted by adding its support to J2EE/Java EE via JAX-RPC and JAX-WS specifications. There is a way to create RESTful services using JAX-WS, however this approach has not gained wide acceptance due to a number of reasons (lack of standardized WSDL binding being one of them). […]