Original URL: https://www.theregister.com/2008/02/25/ws_versus_rest/
Time to balance WS-* and REST
Relative needs
Posted in Channel, 25th February 2008 12:02 GMT
The WS-* stack was conceived and driven forward by IBM and Microsoft, with other vendors cooperating on specifications where they had relevant expertise (Verisign on Security, BEA Systems on transactions and so on). The design philosophy was for a relatively simple and efficient basic mode of operation, with optional features added independently of each other.
More recently, though, something else has taken root among developers building distributed applications: Representational State Transfer (REST). As ever with technology, the debate over WS-* and REST has settled on the death of one technology and the rise of the other. The truth, though, lies somewhere in between.
WS-* is a veritable pyramid of specifications piled on top of Simple Object Access Protocol (SOAP) and Web Services Description Language (WSDL). The first addition was Universal Description, Discovery and Integration (UDDI), followed after a couple of years by WS-Security, then WS-Coordination, WS-Transaction, BPEL, WS-Manageability, WS-Addressing, WS-ReliableMessaging, WS-Federation, WS-MetadataExchange.
Both Java Enterprise Edition (Java EE) and .NET have extensive built-in support for serving and consuming web services. Indeed, as this list clearly shows, Java EE 5 includes no fewer than seven web service related specifications. On the Windows platform, Windows Communication Foundation (WCF) is now the default way of using web services from the .NET Framework. Thanks to IBM, WS-* even provides a suitable framework for building grid applications using WS-ReliableMessaging, WS-Distributed Management, WS-Notification, and WS-ResourceFramework. Good overviews of the vast extent of WS-* and related specifications are offered by Thomas Erl and innoQ (among many others). InnoQ also provides a color poster that graphically illustrates the sheer scale of the WS-* architecture.
Before SOAP was invented, back in 1998, there was Dave Winer's XML-RPC. In contrast to WS-*, XML-RPC was designed to make life easier for individuals and small organizations. Therefore it was kept extremely simple and lightweight, at the cost of giving up most of the sophisticated "optional extras" that WS-* offers. Alongside XML-RPC, a whole range of ad-hoc approaches to lightweight web services have sprung up. These are referred to generically as "XML-over-HTTP".
Which brings us to REST, that mysterious acronym that turns up so frequently in today's media, newsgroups, and blogs. REST is not a language, or a protocol, or an architecture. Strictly speaking, it is an architectural style - specifically, the architectural style of the web.
To build a RESTful web service, all you need to know is:
1. What are the resources to be served? (URIs)
2. In what format is the data encoded? (HTML, XHTML)
3. Which methods are supported by each URI? (GET, PUT, POST)
4. What status codes may be returned? (error, warning, information)
REST boils everything down to bare essentials: nouns (resources), verbs (HTTP operations), and data formats (usually XML applications). It is a cardinal principle that every separate method or function should have its own URI; and, ideally, URIs should never change or be withdrawn.
The REST documentation consists of Roy Fielding’s PhD dissertation, Architectural Styles and the Design of Network-based Software Architectures. Now chief scientist at Day Software in Newport Beach, California, Fielding contributed substantially to the standards behind the web, especially URI, HTTP, and HTML. He also cofounded the Apache project.
The Semantic web, one of W3C's most important initiatives, is RESTful through and through because it is an extension to the web. Its key idea is that web content and metadata should be understandable, so to speak, by programs as well as people. Using Resource Description Framework (RDF), Web Ontology Language (OWL), and other tools, the Semantic web may well sweep away all other web service approaches - if it ever succeeds on a commercial scale.
Given that REST is the architectural style of the web, it is clearly well suited to applications that involve explicitly reading and writing chunks of data. Content syndication, the technique most of us use to follow blogs, is exactly such an application, so it is hardly surprising that RSS and Atom, the two dominant syndication feed formats, are also among the most frequently cited REST examples. (Interestingly enough, Atom uses RDF internally - its name originally stood for "RDF Site Summary" although it is now expanded, if at all, as "Really Simple Syndication").
As long ago as 2001 Jeff Bone neatly summarized the arguments for using REST, in a way that has hardly been improved on since. "It turns out that the best argument for REST is this: there are no applications you can think of which cannot be made to fit into the GET/ PUT / POST / resources / representations model of the world!... with a little design thought up-front, it is complete enough and flexible enough to subsume all the application semantics you might want". Bone also drew a fascinating parallel with the Unix design guideline that "everything is a file"; in REST, resources take the place of files, while the URI address space is the equivalent of a filesystem.
By 2004 a voluble body of WS-* critics was emerging. Sun Microsystems' Tim Bray declared himself the "Loyal WS-Opposition" and Mike Gunderloy told us all to "WS-JustSayNo”. Bray, no stranger to big complex software systems, thought the WS-* stack "bloated, opaque, and insanely complex". Moreover, he reflected: "I look at Google and Amazon and eBay and Salesforce and see them doing tens of millions of transactions a day involving pumping XML back and forth over HTTP, and I can't help noticing that they don't seem to need much WS-apparatus".
Others soon added their own caustic comments, such as this.
When Amazon launched its open-to-all consumer web services, it decided to offer parallel SOAP and "REST" (XML/HTTP) APIs and see which was the most popular. Very early on, it turned out that 85 per cent chose the REST API, which was simpler and easier to get started with. Yahoo! provided REST-style services only, while eBay gave a choice. To begin with, Google's API was SOAP-only, but now it too has REST options - even for GWT.
In April 2006, when Tim Anderson interviewed Tim O'Reilly for Reg Developer, it was becoming clear that the WS-* v REST controversy was a result of market confusion as much as anything else. O'Reilly disclosed that Andrew Layman, one of Microsoft's SOAP architects, had once told him: "That it was actually a Microsoft objective to make the standard sufficiently complex that only the tools would read and write this stuff, and not humans". Which raises another vexed question: is it really a good idea to generate web services automatically from existing code?
The argument rages on, with the REST advocates mostly talking loudest. Here, for instance, are ringing condemnations of WS-* from an IBM employee and a Microsoft employee. It's positively alarming to see how closely they agree. Just for balance, here's Steve Vinoski's take. He's a practical distributed systems architect, an expert in CORBA and most other types of middleware, and quite impartial. But perhaps we should give the last word to Sanjiva Weerawarana, an ex-IBMer who now seems inclined to call down "a plague on both your houses". He's right, of course: WS-* and REST both have their strengths and weaknesses, and neither is perfect for everything.
When confused by too much detail, it pays to go back to first principles. First of all, we should ask ourselves, what are web services exactly? Sad to say, the honest answer is that no one knows - or, at least, not everyone agrees. Some definitions stress the use of XML, while others insist on SOAP or WSDL. Some implementations directly support CICS, Java EE or grids, while others are deliberately lightweight and easy to use.
The next question is whether web services should be designed to fit in as painlessly as possible with existing object-oriented applications and frameworks, or to work as efficiently and cleanly as possible across existing networks? The two objectives are hard to reconcile, if not actually incompatible. Then perhaps we should ask how much it should cost to use web services? Should it be free, as originally envisaged, or should it require the purchase of complicated, expensive proprietary tools and middleware?
Without answering these questions, it is impossible to choose between WS-*, XML/HTTP, REST, and other technical approaches. Even distributed object systems like CORBA, COM+, and RMI work well in certain particular types of application - for instance, those running on fast, reliable networks within a single administration and security domain. They lie at one end of the spectrum, with REST at the far end and WS-* in the middle. REST is particularly suitable for very large networks with huge numbers of clients and servers, where clients may also be servers and vice versa, and where it is convenient to model all operations as reads and writes directed to individual URIs. As for WS-*, its sweet spot lies in systems bigger than those that use distributed objects, and whose networks are further flung, slower, less reliable, and possibly divided between different administrative domains.
Don't expect conclusive answers to this many sided debate any time soon. When it comes to web-scale distributed systems, we simply don't know enough yet about what works and what doesn't. Besides, web services are still a solution in search of new problems. That's always harder than trying to solve a known set of requirements.®
Tom Welsh is a senior consultant with Cutter Consortium's Enterprise Architecture advisory service. Tom has been following OMG and its specifications since 1992.