Re: Web Services War Stories

Hello,

Regarding SOAP being heavyweight, is that something that people just
learn to live with, or is it a choice?

There are pros and cons to SOAP. In many situations, the "heavyweight" issue isn't a big issue. If you call a web service once per day, who cares if it takes an extra 250 milliseconds to run?

Using SOAP saves you from having to code the plumbing yourself. If you have good SOAP tooling then you can just do a call to the SOAP service, and it works.

For example, here's a simple example of calling a SOAP web service from PHP (assuming that $address contains an address you wanted to GeoCode)

<?php
$wsdl = 'http://geocoder.us/dist/eg/clients/GeoCoderPHP.wsdl';
$client = new SoapClient($wsdl);
$result = $client->geocode($address);
echo $result[0]->lat . "\n";
echo $result[0]->long . "\n";
?>

That's very simple to code... (only two of the lines, above are actually calling the web service. The rest is just working with the contents of variables...) It's simple because the tooling does all of the work for you, you don't have to do all of the crazy XML stuff yourself. Really easy to code.

It'd take at least twice as much code to do the same thing with REST. Probably more than that, because the URL would have to be built, and the response would have to be parsed. And if you had to send a document as well (such as an XML or JSON containing data to store in a database or something) then you have to build that, too.

Granted, the REST code will run faster, but the SOAP code is much easier to code.

On the other hand, if you DON'T have good tooling, and have to built the XML data yourself, and parse the response yourself... then SOAP is at least as hard to code as the REST (maybe more so, since the XML tends to be more complex) and therefore the fact that REST is lightweight is a big advantage.

In other cases, where you're doing constant communications (every few seconds) the overhead of SOAP will be a much bigger issue.

That is, if you buy into the frameworks that support it, do you just
go with the flow, because it's easiest? If you're a producer of Web
Services do you just publish that way by default? Would you have to
go out of your way to simplify the interface?

For the most part, simplicity in the SOAP interface is a non-issue, because your caller will have tooling to handle the complexity. You just hand the caller your WSDL, and poof, he can call your web service.

With REST, it's harder... you have to "teach" (often through documentation) your caller how to call your service, because there's no standard for REST. So each call to a RESTful service will be different from others... so everyone needs to read the documentation and understand it, and code it accordingly.

That's a non-issue with SOAP because, again, the tooling does all the work. Give the tool your WSDL, and it "just works." The intelligence is in the tooling.

I read that WSDL/SOAP have the benefit of publishing to a UDDI
directory so people can more easily find your service. Does that
affect the decision?

UDDI really never caught on... it was a big deal at first, but never really gained much momentum.

Personally, if I'm going to call a web service internally, or if I'm going to call it from JavaScript (including a framework) then I use REST, or something similar to REST (such as Sencha's Ajax Proxy -- though, their REST proxy works, too.)

If I'm going to publish the web service as something I expect other people to use (such as customers) I'll make it SOAP, because it's just easier than spending _ALL_ of my time on the phone explaining things to every customer.

Of course, we are a small shop. In a big enterprise, who has separate IT departments scattered around the country or the globe, then SOAP also makes a lot of sense (for the same reasons -- not having to explain everything.)

Finally... I'm often asked to call existing web services, and I don't have any say in how that web service works. in that situation, of course, I don't have a choice, I do whatever they ask. Most of the time (in my experience, anyway) that'll be SOAP. At one time, I'd say 99% of the web services out there were SOAP -- but recently, that has changed, as REST has made huge strides in the market. Now it's more like 70% SOAP.