Network programming: SOAP vs DIY marshalling with XML library?

Question

I know that there are a lot of discussions already on SO about SOAP, bloat, XML, and alternative mechanisms like REST.

Here's the situation. A new team member is really talking up SOAP based upon the difficulty of implementing protocols by hand. He recommends gSOAP (project is all in C++.) He is stating things like WSDL cleaning up lots of messy hand coded C++.

Right now I am handling most networking with XML based text messages, and the expat XML library. So I have some programming effort (not much) associated with modifications to message formats or additions to parameter lists. At the sender end I package up an XML request and send it over a plain old TCP socket. At the receiver I parse the XML using DOM or SAX. Etc. It has worked fine so far. The XML messages are quite compact and average a couple of hundred characters, at most. And I understand every item in those messages.

We want one portion of the product (a server) to be accessible to web sites that are coded using PHP. That is partly driving this idea here, that a SOAP interface will be "easier" for script writers. Everyone on this project believes that SOAP is their salvation.

I see the introduction of a new large library like gSOAP as highly disruptive to the momentum of a mature project.

What I am wondering is if there is a different and more compact way of doing what SOAP gives us. And how to balance claims of gSOAP or other SOAP tools making development life easier against hard reality.

IE, I am being told that WSDL is better, easier, more workmanlike, etc than hand coding C++ using an XML library. That it puts the semantics of the C++ objects right into the declaration of the network messages. The thing is, many of the XML messages that I have defined don't map one for one to a single distinct object at the receiving end.

Or, it is possible that I am worrying about nothing.

But the reality as I scan messages here seems to contradict what I have been told locally.

Answer 1

I'm not buying SOAP.

Don Box's original vision of a Simple Object Access Protocol is anything but simple now. It's become a bloated, design by committee mess.

Throw in all the additional dependencies on bloated libraries and you have a potential mess on your hands.

Tool vendors love SOAP, but I don't see much for anyone else.

Answer 2

If you look around at RESTful interfaces on the net, you'll notice that SOAP is nearly universally avoided. SOAP is such a complex beast that it effectively locks out languages with no existing SOAP package, since nobody is going to implement it themselves. Raw XML, on the other hand, is pretty universal at this point, and not that difficult to implement in-house if necessary.

Answer 3

Here is a classic, hilarious, debunking of SOAP - The "S" stands for Simple". The community I move in is completely converted to REST.

Answer 4

I think that you will find that PHP developers are more likely to prefer RESTful interfaces. Here is a 2003 article about it.

http://onlamp.com/pub/a/php/2003/10/30/amazon_rest.html

RESTful interfaces are a growing phenomenon and if you need to attract developers to your platform it will be easier if you catch the wave.

Having said that, is there a good reason why you cannot support multiple interfaces? This is fairly common in web services that do not have a captive audience. You could support your legacy model, a clean RESTful model and a SOAP/WSDL model. Then take stock after 6 months to a year to see which model is the most popular and least effort to support.

When it comes to making the site more accessible to outsiders, REST has more widespread usage. As far as saving your project, it is possible that SOAP would do this because it demands a certain amount of rigor in interface design, however the same could be said of REST. If this is a key criterion, then you should probably abandon the hand-coded XML and go with a high-level interface design that could be implemented as both REST and SOAP.

I know some people believe that SOAP and REST are fundamentally different approaches, but if you take a RESTful approach to the interface design, you shouldn't have great difficulty in creating a SOAP version. Don't try to do it the other way around though.