Less SOAP

I’ve recently had the displeasure of being introduced to SOAP. If you don’t know what it is, don’t go to find out. The germophobes in the world have turned me off to the necessity of hand washing over time. The introduction of hand sanitizer in every square inch of human existence makes me wonder how long it’s going to be before the superbug comes to wipe us all out. It’s understood that cleanliness can be a virtue, but there’s a point at which it does more harm than good. As a species, we’re making ourselves more susceptible every day to health concerns we could easily have dealt with not so many years ago.

Along those same lines is SOAP. It’s a flexible architecture for transferring data between applications. The S in SOAP stands for simple. On the flexible front, I have to agree. On the simple front, nothing could be further from the truth. The Wikipedia page on SOAP says that its XML-ness promotes human readability. If you then read the following example code snippet, I challenge you to consider it simple. Because SOAP is flexible, it has advantages. It can be used across many transports (HTTP, SMTP, etc). It’s based on a standard data structure: XML. But its aggressive use of namespaces, obfuscated schemas and the necessity of programming language SOAP-based object classes just to deal with the data structure of SOAP make it a nightmare to understand and overly slow in practice.

I suspect the problem with SOAP lies squarely in my own brain. Clearly I am an not intelligent enough to ferret out the reasons why such a method of data collaboration was created when much simpler and potentially transport agnostic methods already exist, like say the HTTP GET using, let’s say, PLAIN TEXT. My hope is that this post will encourage the SOAP advocates to come out of the woodwork and explain to me why it’s so much better than other things which accomplish the same tasks. I’ll let everyone know when my mind has been changed by waving my 99.9% germ-free hands in the air.