InfoQ

News

The REST versus WS-* war is over!

Posted by Mark Little on Jul 04, 2007 07:16 AM

Community
SOA
Topics
Web Services ,
REST
Tags
Web services
In his blog, David Chappell puts down what a lot of people have been slowly and quietly accepting over the past year or so:
To anybody who's paying attention and who's not a hopeless partisan, the war between REST and WS-* is over. The war ended in a truce rather than crushing victory for one side--it's Korea, not World War II. The now-obvious truth is that both technologies have value, and both will be used going forward.
Ignoring whether the debate was ever about REST versus WS-* or REST versus SOA, this level of acceptance (or fence sitting) has been coming for a while. As David goes on to point out:
... take a look at Microsoft's forthcoming support for creating RESTful applications in the next release of Windows Communication Foundation (WCF). The official Java world is also on board, with the impending creation of JAX-RS.
But Microsoft and others have been saying good things about REST and WS-* for several years, so this shouldn't come as a surprise. Only a few people still believe that Web Services are a global panacea. The same for REST. But this does raise the obvious question: when to use REST and when to use WS-*? In David's opinion:
A RESTful approach is a natural for data-oriented applications that focus on create/read/update/delete scenarios. Lots and lots of apps fit this model, especially on the public Internet. A solution based on WS-* makes more sense for service/method-oriented applications, especially those that need more advanced behaviors such as transactions and more-than-basic security.
But Mark Baker disagrees:
He’ll get no argument from me that REST is good for data-oriented applications, but saying that it’s only good for the subset that fit the CRUD model is wrong. It’s wrong because CRUD doesn’t have an equivalent for HTTP POST. Once you incorporate POST into your repertoire, then you can do all kinds of interesting things like, say, ordering stuff.
Mark's open to education on this point, with:
Perhaps David - or anybody else - could point me towards a data oriented application which can’t fit (well) into such a model (not REST, just the uniform interface part).
So when David finishes his article with:
It's a real pleasure to see fanaticism recede and reason win the day. The war really is over.
is he right, or are we just in a lull while the generals decide on new battle strategies?

8 comments

Reply

Some people still holding out! by Paul Fremantle Posted Jul 4, 2007 9:10 AM
Re: Some people still holding out! by Mark Little Posted Jul 4, 2007 10:02 AM
The war is over. by Alex MacCaw Posted Jul 4, 2007 12:06 PM
Re: The war is over. by Mark Little Posted Jul 4, 2007 5:24 PM
There was a war? by Jonathan Allen Posted Jul 4, 2007 10:58 PM
REST vs. WS-* is not the real issue by Faisal Waris Posted Jul 5, 2007 1:56 PM
Re: REST vs. WS-* is not the real issue by Mark Little Posted Jul 5, 2007 2:54 PM
REST is quietly taking over by David Booth Posted Jan 14, 2008 4:21 PM
  1. Back to top

    Some people still holding out!

    Jul 4, 2007 9:10 AM by Paul Fremantle

    Reading the article, it occurs to me that the war is over, some people just don't realize it :-)

    After World War II, some Japanese soldiers kept fighting on. One of them Hiroo Onoda kept going until 1974! I'm sure there are going to be a few people in this battle who also refuse to accept the war is over, but I hope this doesn't drag on that long.

  2. Back to top

    Re: Some people still holding out!

    Jul 4, 2007 10:02 AM by Mark Little

    I knew the war analogy would bring out some good comparisons ;-)

    But I agree with you. I think the time has come to draw a line under this debate/war and accept that there's good and bad with both approaches. And does anyone really believe that WS-*, SOA or REST are the pinacles of our technological advancement? Surely there are things that will come after?!

  3. Back to top

    The war is over.

    Jul 4, 2007 12:06 PM by Alex MacCaw

    I think the war is over, and REST won. I admit I move in very Rails centric circles, but I haven't had people requesting me to re-factor their applications to support WS-*, but have many requests for REST. REST certainly integrates well with Rails but, IMHO, its biggest asset is the way it integrates with html, abolishing the idea that APIs and client interfaces have to be separate - you can support and build both in one go and kill two birds with one stone.

  4. Back to top

    Re: The war is over.

    Jul 4, 2007 5:24 PM by Mark Little

    I'd say this is just an example of where you're using the right tool for you. But that doesn't mean REST is right everywhere, or vice versa.

    I've been involved with REST and WS-* deployments as far back as 1999/2000 and can say that each has it's uses. But one of the most obvious advantages Web Services have over REST (at the moment) is standards and interoperability for complex capabilities. Show me the equivalent of WS-TX, WS-RX, WS-SX, WS-Management etc. Sure it's relatively easy to get one or two vendors to agree on how to do these things using POX/REST ad hoc, but until the likes of IBM, MSFT, Oracle etc. get together and agree on how to do these things, you're always going to be at a disadvantage.

    Now we can have a discussion about whether or not you really want to do these things at all "across the Web", but that ignores the fact that many users do want to do this so we (as an industry) can't stick our heads in the sand. There are good enough reasons to do these things and if you need to, then WS-* is the best approach. REST has it's advantages over WS-*, and you're right: simplicity is a key element there, though there are others.

    Will IBM, MSFT et al get together and produce an equivalent of the Web Services architecture based on REST principles? I doubt it: WS-* has been a lot of time and effort so far, and I don't think the industry has the same impetus that existed back in 1999. Should they do the work if they could? I'm not so sure. I'd like to see how far we can get by using the two technologies as complimentary tools, rather than trying to blur the boundaries.

  5. Back to top

    There was a war?

    Jul 4, 2007 10:58 PM by Jonathan Allen

    I didn't notice. At my day job we are too busy actually building SOA systems to care about REST vs WS-*. The information exchange format can be anything from web services to raw XML over TCP to CSV files uploaded via FTP or even email. It all depends on what tech we already have in place, what our partners are using, and what happens to be more expedient.

    It seems to me that SOA is just a new name for an old concept, one that we have been depending on since first company using a computer realized they needed to talk to the second.

    As for REST vs WS-*, that will be decided by market forces, not thought leaders. The guys in the treches actually implementing this stuff will ultimately determine what is used in most shops, and most of them will do so without talking about it.

  6. Back to top

    REST vs. WS-* is not the real issue

    Jul 5, 2007 1:56 PM by Faisal Waris

    REST is an architectural style that can also be easily used with WS* (see WS-Addressing, WS-Transfer, WS-Enumeration).

    Most purported REST implementations are actually doing XML-over-HTTP (not really applying REST principles).

    So the real issue is should we do SOAP or just HTTP (with our without XML).

    HTTP has been around much longer than SOAP and hence it is supported on most platforms very well. This is why it is more appealing. SOAP support is slowly rolling out and is going through growing pains.

    Architecturally speaking, SOAP provides coarse-grained aspect orientation (through the concept of SOAP intermediaries and SOAP 'features'). This is being leveraged well by the various WS* protocols.

    Longer-term I think SOAP will provide a robustness that plain HTTP will not be able to match and so for many integration / SOA needs SOAP would be right solution. Solutions that require reliability, transactionality and robust security.

    For read-only access and 'mashups', HTTP based accessed would continue to be a convenient alternative.

    But please don't use REST as a synonym for XML-over-HTTP.

    Faisal

  7. Back to top

    Re: REST vs. WS-* is not the real issue

    Jul 5, 2007 2:54 PM by Mark Little

    REST is an architectural style that can also be easily used with WS* (see WS-Addressing, WS-Transfer, WS-Enumeration).


    Well we've had some of this discussion before. But what you're saying is partly related to the "Is it REST vs WS-* or REST vs SOA" debate. And the TAG had some interesting debates around that too.


    Most purported REST implementations are actually doing XML-over-HTTP (not really applying REST principles).

    So the real issue is should we do SOAP or just HTTP (with our without XML).


    You might find this discussion interesting. It's a little old now and from back when Mark was chair of the WS-A working group, but it's no less relevant now.


    But please don't use REST as a synonym for XML-over-HTTP.


    I don't think anyone in this discussion has made that statement. However, it is true to say that when many people talk about REST they are implicitly assuming HTML/HTTP simply because the Web is always used as the reference implementation.

  8. Back to top

    REST is quietly taking over

    Jan 14, 2008 4:21 PM by David Booth

    Yes, the war is over, and perhaps it is a truce of sorts, but it isn't because the zealots have realized that REST and WS* are both useful. It is because:

    - it's clear that REST has won the war of ideas; and

    - it's also clear that REST does not (yet) have the big vendor or tooling support that WS* has.

    The net result is that WS* is not going away any time soon, but REST is quietly taking over.

Exclusive Content

Book Except and Interview : Aptana RadRails, An IDE for Rails Development

Aptana RadRails: An IDE for Rails Development by Javier Ramírez discusses the latest Aptana RadRails IDE, a development environment for creating Ruby on Rails applications.

Fast Bytecodes for Funny Languages

Cliff Click discusses how to optimize generated bytecode for running on the JVM. Click analyzes and reports on several JVM languages and shows several places where they could increase performance.

Scott Ambler On Agile’s Present and Future

Scott Ambler, Practice Lead for Agile Development at IBM, speaks on the current status of the Agile community and practices having a look at the perspective of the Agile’s future.

Manager's Introduction to Test-Driven Development

Dave Nicolette and Karl Scotland try to introduce non-technical managers to one of the most popular Agile development techniques: Test-Driven Development (TDD).

Structured Event Streaming with Smooks

Smooks is best known for its transformation capabilities, but in this article Tom Fennelly describes how you can also use it for structured event streaming.

How to Work With Business Leaders to Manage Architectural Change

Successful architectures evolve over time to meet changing business requirements. Luke Hohmann presents how to collaborate with key members of your business to manage architectural changes.

Colors and the UI

In this article, Dr. Tobias Komischke explains how colors used in a GUI can influence our interaction with a computer and offers advice on using the appropriate colors for the interface.

Building your next service with the Atom Publishing Protocol

In his presentation, recorded at QCon San Francisco, MuleSource architect Dan Diephouse explores ways to use the Atom Publishing Protocol (AtomPub) when building services in a RESTful way.