BT

Facilitating the Spread of Knowledge and Innovation in Professional Software Development

Write for InfoQ

Topics

Choose your language

InfoQ Homepage News The REST versus WS-* war is over!

The REST versus WS-* war is over!

Bookmarks
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?

Rate this Article

Adoption
Style

Hello stranger!

You need to Register an InfoQ account or or login to post comments. But there's so much more behind being registered.

Get the most out of the InfoQ experience.

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Community comments

  • Some people still holding out!

    by Paul Fremantle,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    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.

  • Re: Some people still holding out!

    by Mark Little,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    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?!

  • The war is over.

    by Alex MacCaw,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    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.

  • Re: The war is over.

    by Mark Little,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    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.

  • There was a war?

    by Jonathan Allen,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    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.

  • REST vs. WS-* is not the real issue

    by Faisal Waris,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    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

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

    by Mark Little,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    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.

  • REST is quietly taking over

    by David Booth,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    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.

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

BT