Actually, a more accurate description of the RESTy perspective would be "we think contract-last Web Services" is half the problem of WS interop, and WSDL is the second half". It is a language too hard for humans to write, and is full of ambiguity, especially when used with Xml Schema. Together, XSD and WSDL are so unusable that most people are correctly scared to hand-write WSDL, yet mistakenly opt to their SOAP stack do it instead. Given that most of WSDL (1.x) is dedicated to defining the methods/services of endpoints, it is completely irrelevant to REST, where the interface is uniform across all resources.Another poster says that that web services in general are changing, in that "for users all of this is meaningless: users know what they like and what they like we tend to call AJAX, and the only thing missing is decent security, and REST vs. WS-* seems only tangential to that..." Why would you choose REST or SOAP (or something else) for your applications? What drives your decision?
News: alexismp explains "Why would I need to be reliable?"
The Glassfish Aquarium blog has a post called "Why would I need to be reliable?," in which alexismp suggests a few conditions under which SOAP is preferable to REST for web services. Primary points: contract-first development, lack of HTTP reliability, and lack of point-to-point security. Note that it's not suggesting SOAP over REST for all cases - simply pointing out some cases where SOAP has an advantage. Some commenters have already weighed in: Steve Loughran points out that contract-first isn't all it's cracked up to be (and it's not often cracked up to be much!):
- Posted by: Joseph Ottinger
- Posted on: February 28 2007 08:11 EST
- Why REST by Edmon Begoli on February 28 2007 10:01 EST
- Leave the REST to SOAP. by Ryan Heaton on February 28 2007 12:11 EST
- Re: alexismp explains "Why would I need to be reliable?" by Paul Campbell on March 01 2007 06:43 EST
- Re: alexismp explains "Why would I need to be reliable?" by Bostjan Dolenc on March 05 2007 07:11 EST
This is a subject that has been discussed at lenght over and over again. I can personally provide three type of answers to why REST over SOAP - Personal, Cynical and Technical Personal reasons are simple: I am convinced that REST is one more of these very simple computing solutions (like SMTP, shell script, HTML, SQL ... ) that are very simple and that completely leverage existing infrastructure enough and that are effective enough to solve wide variety of problems 'as is'. Cynical reason is my belief that SOAP is a component of a what I called a Gartner Driven Architecture (GOA) which is synonim for Vendor Driven Architecture (VOA). In my possibly skewed view of IT history that I have witnessed first hand IBM took Microsoft's XML based object remoting ideas (S.O.A.P.), and propagated it to a Web Services standard (SOAP,WSDL,UDDI) under the premises of being a basis for decoupled, interoperable, over-standardized SOA/ESB architectures. What I really see underneath is major vendors' (IBM,BEA,Oracle,WebMethods ...) need to architecturally justify selling us very expensive line of products for messaging, transformation, serving, workflowing and modelling. Than on top of that add ultra-expensive ESB which is advertised as a vaccine for all our enterprise ilnesses. Technical reasons are really arguments for considering REST architectural style an essential element of what is called a WOA or Web Oriented Architecture. I recommend reading this particular article: http://blogs.zdnet.com/Hinchcliffe/?p=27 and this one: http://blogs.zdnet.com/Hinchcliffe/?p=43 to get some further clarification on these arguments. As of security and design by contract, I would not argue that these two have not been very thought out in the SOAP based Web Services architecture. I will also say that for the sake of standardization and this low-coupling approach SOAP web services have felt complex, very WS-* tool dependent and very over-engineered (like J2EE or specifically EJB 2.1) My choice, and I am lucky to have one, is to go with REST and to try to solve all interoperability problems that way. I am yet to run into a stumbling block with using REST.
In case any of you are interested, I've blogged about my own findings on the deficiencies of REST, despite considering myself a REST advocate. http://sanitystack.blogspot.com/2007/01/leave-rest-to-soap.html My biggest gripe is more with die-hard REST fanaticism than it is with REST itself. Despite the arguments to the contrary of the restafarians, REST doesn't fit all service models. (And don't try to tell me that if REST doesn't fit, the problem lies with the service model!) Do what you can with REST, but "leave the REST to SOAP."
Its interesting to note that REST is really just an adaptation of a decades old network management protocol called CMIP: http://en.wikipedia.org/wiki/Common_management_interface_protocol Since REST is obviously pitched at acheiving the same goal as CMIP, namely interaction with a stateful heirachical resource model via a descrete set of operations, maybe we can learn something here. CMIP provides seperate operations for invoking a "method" on a resource vs changing an attribute of a resource and I see the main problem with REST is that this distinction needs to be achived by some convention. Paul C
REST is as much an adaptation od CMIP as it's an adaptation of SQL. The latter can also be vaguely mapped to REST via SELECT->GET, INSERT->PUT, UPDATE->POST and DELETE->DELETE. But as usual, the devil lies in the details - in the actual semantics attached to the operations and the data these operations act upon. Also, there's no equivalent for CMIP's ACTION. REST strongly proscribes such operations. In the end, REST is just an architecture style, formulated by Roy Fielding to make sense of the whole "web thingamajing". The implementation, which can be compared to SOAP, CMIP or SQL is HTTP.