转自：http://www.davidchappell.com/blog/2007/06/rest-vs-ws-war-is-over-if-you-want-it.html

REST vs. WS-*: War is Over (If You Want It)   

Wednesday, June 27, 2007

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.

If you doubt this, take a look at Microsoft's [URL=http://sessions.visitmix.com/default.asp?event=1011&session=2012&pid=DEV03&disc=&id=1512&year=2007&search=DEV03]forthcoming support [/URL]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 [URL=http://jcp.org/en/jsr/detail?id=311]JAX-RS[/URL]. Since both worlds also have good support for the WS-* approach, developers will be able to choose the approach that's best for a particular application.

Two big questions remain. The first is, What exactly is REST? By far the best and clearest definition I've seen is provided by [URL=http://www.amazon.com/RESTful-Web-Services-Leonard-Richardson/dp/0596529260/ref=pd_bbs_sr_1/002-2732234-0308859?ie=UTF8&s=books&qid=1183009793&sr=8-1]RESTful Web Services[/URL], a wonderful book by Leonard Richardson and Sam Ruby. If everybody can buy into the measures of RESTfulness this book provides, we can all avoid lots of future arguments. (As a side benefit, it will let most of us get by without reading Roy Fielding's [URL=http://www.ics.uci.edu/~fielding/pubs/dissertation/top.htm]PhD thesis[/URL], the canonical text on REST.)

The second question is, When should each approach be used? Whatever partisans may claim, neither technology is right for every situation. While hammering out a true understanding of this will likely take some time, the basic outlines are clear. 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. (Doubt this last point? Look up "Security" in the index of the Richardson/Ruby book: Exactly one page number is listed.)

Maybe the problem was always really just naming. Applying the term "Web services" to SOAP/WS-* applications doesn't make much sense. The SOAP/WS-* stack is actually the culmination of a twenty-year vendor battle over distributed computing protocols, the end of a line that included OSF DCE, CORBA, DCOM, Java RMI, and .NET Remoting. By finally agreeing on this standard set of technologies, the vendors have put an end to their long struggle. Yet other than the fact that SOAP is commonly sent over HTTP to get through firewalls, these technologies have nothing to do with the Web. REST, on the other hand, is deeply Web-based--it's just a way to create distributed applications using standard Web technologies. Given this, REST is far more deserving of the "Web services" moniker than is the SOAP/WS-* approach.

I've always thought REST was interesting, starting with the [URL=http://www.davidchappell.com/articles/article_REST_web_services.html]first piece [/URL]I wrote on it almost five years ago. I've also been a fan of SOAP and WS-*, partly because I've spent a large part of my career on that vendor battlefield. It's a real pleasure to see fanaticism recede and reason win the day. The war really is over.