Financial Market Data Web Services – Xignite Blog

I am a late comer to the SOAP vs. REST debate, mainly because this blog started after the battle began raging. But a recent post by Raymond Yee–who is writing a book about mashups–suggested a reaction.

Raymond’s main point is that SOAP requires a developer to have deep knowledge of the protocols (WSDL and SOAP) to use web services effectively and that it is "so much  easier to get started with REST."

I disagree violently. The knowledge of SOAP and WSDL you need all depends on the SOAP toolkit you use.

I’ll take an analogy; Do we require internet users to know HTML to navigate the web? No we don’t. On the client side, the browser takes care of turning HTML into beautiful usable web pages. If end users had to read HTML pages in plain text they would find the web very obscure indeed.

On the server side, if you are writing your HTML by hand, you will definitely need to know the details of the protocol. But if you use a good advanced IDE that lets you write pages in a WYSIWYG fashion, you can build a web site without knowing anything about HTML.

So it all depends on the tools (client and server side) and how well they hide the protocol from you.

If you want to write a web service by hand, you will have to know SOAP and WSDL. If you use a good toolkit, all you have to do is write a function call and you have a web service. If you want to consume a web service without a good SOAP toolkit, you will have to learn the standards but not otherwise.

We have written dozens of web services which collectively have served billions of SOAP requests to hundreds of firms around the world yet we have never read the SOAP specs and we can barely read a WSDL by hand. All we had to do was to write meaningful function calls (which is an art in itself).

Our clients who use good SOAP toolkit can go from pointing to our WSDLs to consuming data in their application in less than 60 seconds without a hint of what the protocols are about. This is not something you can do with REST yet (WADL might be able to change that).

Clients who come to us with more primitive languages will tend to spend more time working out the details of the integration.

It seems that SOAP’s bad rap comes from those who just have not wanted to use more advanced SOAP toolkits.

It’s very sad indeed. It is as if back in 1996 we had abandoned the promise of the web and stopped building web pages because a bunch of people insisted in using a text editor instead of a browser to open HTML pages and complained about how unreadable this HTML was. Come on.

To his credit, Raymond is very open to being convinced. He wants to "be shown where my thinking is wrong  and how I can start using SOAP and WSDL with ease in PHP, Python, etc."

Unfortunately, and with due respect to the fantastic tools PHP and Pythons are, they are not on the top of my list of the "better SOAP toolkits"–at least in their editor form. We had to handhold too many developers using those to have them make the cut. I suppose that if you use a nice IDE on top of those, things are easier. But they don’t require you to know SOAP and WSDL to make them work.