There was a short-lived tireblogging trend a few months ago, of which this was an example. It’s an account of flat-tire fixing in Nigeria; tube tires are commonly used, which is an annoyance because of the “pointy paraphernalia” often found on West African roads. A cottage industry of “Vulcanizers” (tire patching businesses) has grown up to make the frequent fixes needed. The tubeless alternative generally requires a fancy and expensive air pressurizer to work with, so it’s not as widely used.
I was reminded of this tale while reading the latest instance of the SOAP vs. REST permathread on the xml-dev list. Dare Obasanjo characterizes the difference as rich vs. reach, which a lot of people picked up on as a useful distinction. But while Dare means “rich” in the sense of “richer, more fully featured”, some others in the thread provide evidence that you have to be richer to afford SOAP! Leigh Dodds notes:
There was a lot more pain involved in implementing even simple SOAP services, and debugging them once they were up and running. We’re now using RESTful APIs and these have proved to be successful. They also feel easier to work with: I’ve been merrily applying XSLT to RESTful interfaces to generate HTML forms for applications, shell scripts using curl to implement management and testing tools. Feels a lot more agile. …
I’ve also noticed that our RESTful APIs promote a better understanding of our internal models: rather than a list of function calls, we’re sharing resource models. Not to be sniffed at for a small shop that needs to be able to move engineers between projects easily.
Elsewhere in this thread, Michael Champion provides specifics about the richness he think you give up with REST: “confidentiality, reliability, and protocol neutrality”. But I’m not sure I buy the idea that you miss out without SOAP.
First, confidentiality: As Elliotte Rusty Harold points out, it’s not like XML Encryption doesn’t work on arbitrary XML as well as SOAP messages — and of course the same goes for XML Signature. (WS-Security is a profile of these for web services that contains some good work, but it’s an extremely generative framework and must be further profiled to be used in a secure and interoperable way — one proposal suggested that it needs scores or hundreds of templates just to ensure security! Profiling XML Encryption and XML Signature directly for a generic XML-over-HTTP messaging system could easily be just as functional as WS-Security.)
Second, reliability: Although IBM’s proposal from a couple of years ago for reliability with HTTP, called HTTPR, hasn’t swept the distributed computing world, we now have the credible HTTPLR proposal from Bill de hÓra. Choices do exist here.
Finally, protocol neutrality: I’m confused as to why this is an inherent good. Even if you’re neutral wrt HTTP, don’t you have to be specific wrt SOAP? I understand that there’s the potential for benefit as you move up in abstraction, but there’s the potential for cost as well, since each new higher layer tends, for a significant length of time, to be less mature, less well standardized, less interoperable, etc. And of course, what might be called the “SOAP family of specifications” (a phrase that gives me pause, especially in light of Norm’s post on problems in the XML family of specifications) has given rise to opportunities for, um, let’s call it vendor job security that no longer exist at the widely deployed level below.
I’m not against luxury items — lovely sturdy Mercedes tubeless tires — for those who can afford them, but it seems that the technologies with “reach” have achieved a fair amount of richness using common items that can be found around the home, and deserve not to be dismissed as mere toys. Reach is powerful all by itself. Perhaps the critical tube-tires-and-Vulcanizers lesson is that simpler materials and technologies often have a better habitability quotient, something Leigh Dodds’ comment quoted above demonstrates. I don’t often see this factor taken into account explicitly, but it makes a critical difference at the economic margin — and keeping in mind that “reach” is another way of saying “wider adoption”, I’d venture to say that good habitability is a necessary condition for it.
Hi Eve,
I don’t think anyone must use SOAP. Particularly if your XML services are already ONLY exposed over HTTP/IP. But what if you don’t have an HTTP server, and/or you want to receive messages over some other transport (perhaps without any “transport-layer” headers)? One alternative would be to put everything in the body of the message, but that doesn’t seem to be a good architecture if you want to run multiple services. The SOAP header abstraction enables things that don’t currently have full HTTPDs running,and may not have such things for some time, to provide XML-based services. Talk about extending your reach ;) Wouldn’t you agree that this is more elegant than putting potentially duplicated information into an application message?
Hi John! You’re right that it’s more elegant, but it makes an assumption that the new higher SOAP layer is deployed everywhere (or at least in more places than HTTP is), which is a bit of a leap. There’s no problem that another layer of abstraction can’t make more resource-intensive…uh, rather…solve.