I was intrigued by the REST support in JAX-WS. REST style could be very useful in certain situations,
not to mention the fact that there are already many REST-style services out there.
While I don’t want to get into SOAP vs. REST debate here I still want to quickly mention one
very important REST advantage, which is security.
Since each service call operation in REST is an HTTP GET URL, it makes it easy to use
traditional Web authorization schemes, including Apache mod_authnz or J2EE declarative security defined in web.xml.
Contrast that with SOAP, which requires looking inside the message to figure out what security policy should be applied.
Another side of it is auditing and monitoring. With REST I can easily see all the details of the requests to my web service
operations just by looking at the Web server’s access log and/or using one of the numerous log analysis tools.
SOAP does not give me this information automatically; different application servers and ESB products may provide these capabilities, but there is no guarantee (since it is not part of any specification).
In any event, REST has its place and so it’s nice to see that JAX-WS authors recognized it.
Unfortunately, upon closer examination, it turned out that REST support in JAX-WS is pretty shallow.
REST is really a second class citizen compared to SOAP. Here’s why I came to this conclusion:
-
Automatic WSDL generation (when using annotations in service implementation class) is not supported.
I was expecting to see the support of HTTP GET binding defined in WSDL 1.1, but it is not there.
In general, the spec does not mandate any WSDL to Java or Java to WSDL binding support for REST. -
Object serialization/deserialization is not supported either. This is not unexpected since mapping of a complex object graph to name/value pair GET string may be non-trivial. But I don’t see a problem of doing it for simple flat objects that don’t have nesting.
- Consequently, in order to use REST, one has to rely on dispatcher API on the client and so the query string has to be created manually. Same is happening on the server where developers have to use WebServiceContext and parse the query string manually.
In short, using REST requires some low-level programming; its support is clearly limited compared to SOAP.
What I would like to see is the ability to implement a RESTful service by simply adding
@BindingType(value=HTTPBinding.HTTP_BINDING)
annotation without having to make any other changes relative to a regular SOAP service (or client).
Clearly, we’re not there yet.
Tags: Web services, SOAP, REST
I could not agree more. Dispatch interface is so hard to use!
You know, this was posted in 2006, but it still holds true, doesn’t it? I mean, do we still have to use the Dispatcher API? In June of 2008?