WS-*! vs. REST

WS-*! vs. REST

Both claim that it is "easy” to build distributed business applications using their favorite technological approach.

In fact, there is no easy way to build distributed applications; it's simply a hard problem. WS-* and REST (Representational State Transfer) each has its own strengths and weaknesses.
There are a great many services that do not need WS-*. As long as your requirements are satisfied by the security offered by HTTPS and HTTP Basic Authentication, and you don't need message reliability or transactions, just using REST is the right answer.

To look at this at a lower level, if you're using SOAP to communicate and don't have any headers, then SOAP is not adding any value over a simple XML-over-HTTP approach. Switch to REST instead.

On the other hand, while there are many services that do not need rigorous security and reliability at the message exchange level, there are also a great number that most certainly do. For example, if you're dealing with medical records, end-to-end security and reliability are absolutely essential.

In that case, you do need the WS-* protocols over HTTP; WS-* is essentially a set of standard, interoperable protocols to achieve these qualities of interaction over any underlying protocol, including HTTP. The strength and value of WS-* is that all the core parts of WS-* are now standards and are supported by ALL major and minor vendors.

If you don't use these, you need to essentially invent similar protocols over basic HTTP, which eventually would result in REST-*!

XML is not the best data communications format but XML is simply the language that everybody has accepted. Those who claim that JSON (JavaScript Object Notation) is the best language to communicate in disregard the fact that we can't use JSON out-of-the-box from a mainframe to a cell phone in a way that is already possible with XML. Moreover JSON doesn't come with the rich set of tools that XML does: XPath, XSLT, XML Schema, Relax NG, etc.

JSON is great for AJAX scenarios, but it’s not in the same league as XML as a universal data format, especially when the data is not serialized data structures but rather documents.

REST takes the approach that the media type you get back from the server is a sufficient description of what that URI is supposed to return. While that is sufficient for the dynamic environment of the Web, where the browser simply has to use the media type to display the content in a human-readable form, developers writing programs need to know beforehand (i.e., at development time) what they will get when they GET a specific URL. Without that, there can't be any tools that make it easier to process the data. REST fanatics argue that such tools represent a form of coupling and hence are bad for the loosely coupled architecture of the Web.

WSDL is by no means the best possible description language but it is supported by all major vendors. Until we get a more widely accepted replacement, if you're writing Web services, you should describe them in WSDL even if they're REST-based services. The recently standardized version of WSDL (2.0) is significantly improved from WSDL 1.1 and offers a very nice and simple way to describe both REST-based and non-REST-based services.

Both camps are guilty of promoting this fantasy that you can simply take legacy apps and make them into a WS-* or REST service. Despite WS-* fans’ claims to the contrary, there’s no way you can simply take your old classes and magically SOA-enable them. You need code that understands the proper granularity of interactions in a SOA and the underlying business processes, and then you can make them into a service.

Creating a REST-based interaction with an application is no trivial matter either. In fact, there's still quite a bit of art in creating proper REST services, and tooling support is minimal to nonexistent. For certain applications, of course, there is a natural and simple mapping (as with certain other applications for WS-*), but otherwise you need to be a REST artist.

To create a good REST-based interface, you need to understand REST (which by itself can be quite tiring), figure out how to create the proper resource structure for your artifacts, and finally figure out how to create and manage links between them. The last part is nontrivial, but that represents the “hypermedia as the engine of application state” mantra of REST, which is critical for achieving many of the scalability benefits. REST may be easy for simple cases, but it will not afford you much rest when building real systems.

With so many half-truths, obfuscations and outright lies around WS-* and REST, it’s tempting to toss them both out the window. But for today’s distributed applications, WS-* and REST are two of the most viable and useful platforms available.

Instead, enterprise architects should consider adopting a heterogeneous approach to Web services that capitalizes on the strengths of each. For simple delivery or exchange of messages, REST offers a quick, clean, dependable approach. For more sophisticated services and SOA deployments, the rich WS-* stack provides proven, standard protocols for secure, reliable and transactional services.