Rest In Soap

Rest In Soap sounds better than Rest in Peace, or Rest in Pieces, or ...

There is some REST in SoapProtocol, despite SoapRpcBreaksRest. Most REST implementations without SOAP are not "pure" anyway. And this page is a discussion of the two main WebServices implementation paths.

News and developments

Since 2005, the year where WSI-* become implementations. For example, "second coming DotNet" - WebServicesExtensions realization in products such as DotNetFramework for VisualStudioWhidbey

Interop with Soap and Rest blog by StuCarlton? Mar05 at http://www.stucharlton.com/blog/archives/000074.html

Both REST and SOAP appear to be important in the realization of WebServices, and both speak Xml. See, for example, XML Europe 2004 report at http://www.xml.com/pub/a/2004/05/05/xmleu.html for more details. Another Amazon.com UserStory regarding REST and SOAP is discussed a bit within http://www.onlamp.com/pub/a/php/2003/10/30/amazon_rest.html or http://www.oreillynet.com/pub/wlg/3005.

REST is an architectural style (see RestArchitecturalStyle) and SOAP (SimpleObjectAccessProtocol) is an implementation. RestArchitecturalStyle includes an intense discussion on whether SOAP can or cannot converge with REST.

I do not understand what is wrong with SOAP being RESTless, but I can refer you to http://www.intertwingly.net/stories/2002/07/20/restSoap.html which suggests REST has the Xlink that SOAP misses out, and SOAP has the Stored Procedure equivalent capabilities not in REST.

For anyone who is interested, Tim Bray (creator of Xml 1.0 spec) also has something for the rest of us at http://www.tbray.org/ongoing/When/200x/2003/05/12/SoapAgain

For MicrosoftSlaves in particular, MSDN talks about SOAPless WebService and the REST at http://msdn.microsoft.com/msdnmag/issues/03/05/XMLFiles/default.aspx

And if you still got miles to go before you can rest, go lookup a definition at http://searchwebservices.techtarget.com/sDefinition/0,,sid26_gci823682,00.html

Yet more exercise before sleep? Blow some SOAP bubbles at http://searchwebservices.techtarget.com/qna/0,289202,sid26_gci823342,00.html.

REST programming is not simple, due to and huge URL lists

And data formats may have to be negotiated in all these little (simple) interactions

BobbyWoolf Aug05 viewpoints

He has probably not attended SunOne conference in 05, at which there were loud complaints about absence of WebServicesDescriptionLanguage (WSDL) interoperability.

Moved from RestArchitecturalStyle

Without getting buried in philosophy, there is a purely pragmatic rationale favoring REST.

SOAP needs a whole new suite of tools for development, whereas REST services can be built with existing web application development tools. SOAP involves a significant learning curve, whereas REST is a minor variation on everyday web architecture. Since SOAP entails a significant investment compared to REST, it needs to justify its existence.

Would you see REST being used to implement security provisions as easily as SOAP based implementations where addons like WebServicesSecurity are being standardized? -- dl

I'm no expert, but seeing that SOAP extends the function call paradigm, we'd expect it to need exceptional security. REST rides on HTTP protocols that already have confidentiality, authentication and authorization taken care of. What's missing? --mt

I would not use the word "missing" in the sense that REST should include these. However modern day business transactions have many additional concerns (e.g. performance). For companies who have bitten the bullet to use "international standards" (e.g. those of OasisOrganization) there are probably better shared understanding of how to address the additional concerns (caveat: standards are moving targets). For companies that dont do that, they have to liaise with the individual partnering firm how to build the necessary provisions (e.g. reliability). And probably a different mechanism with a different partner. The cost of these "separate, link specific interfaces" can add up quickly. -- dl

SoapToolkit old stuff

Saw June2004 MSDN article to migrating from SoapToolkit to DotNet. Although the original deadline of 1Jul removal of SoapToolkit has been extended to 2005, it is still on the way out, once DotNet equivalent functionality matures.

I am still trying to figure out XmlAndSoapAreGoodForWhat, and will give SoapToolkit a tryout before it rests in peace, or pieces? (see SoapRpcBreaksRest)

If I get any interesting response in my TekTips? forum post about "appropriate use of SoapToolkit" I will probably share the information with whoever interested in what SoapSellers got to sell.

--dl

CategoryXml CategoryCommunicationProtocol

EditText of this page (last edited August 26, 2005) or FindPage with title or text search