
SOAP: The 'S' stands for simple (not really) - preek
http://harmful.cat-v.org/software/xml/soap/simple
======
Sidnicious
This is great. My (so far, only) experience with SOAP started when my boss
asking me to investigate the new version of a (very big) vendor's SOAP API.
Support for the old version of the API was being dropped in a few days.

It turns out that our framework has SOAP built in, so I had it suck in the
WSDL and make a sample request. It was rejected with a generic error. As it
turns out, our framework was generating requests that looked like this
(simplified with much SOAP nonsense stripped out):

    
    
      <SOAP-ENV:Envelope>
        <Authenticate xmlns="http://bigcorp.example.com/elements/global">…</Authenticate>
      </SOAP-ENV:Envelope>
    

…and the requests in the API documentation look like this:

    
    
      <SOAP-ENV:Envelope xmlns:bigcorp="http://bigcorp.example.com/elements/global">
        <bigcorp:Authenticate>…</bigcorp:Authenticate>
      </SOAP-ENV:Envelope>
    

the difference being that our framework declares a "default namespace", while
their API expected a "namespace prefix". As far as I could tell from _reading
the spec_ (always a bad sign when you're using a standard that both ends
support) the difference shouldn't matter.

\- - -

I went to my boss. He showed me the old code; all the requests it needs to
make are hardcoded based on the docs, and substitute XML-encoded variables in
the right places.

Save a few minor changes, that's the process we still use today, and it
fucking works.

~~~
dfranke
Something's seriously messed up if, once the XML has been parsed, their code
can even _tell_ the difference between those two constructs, much less care.

------
lkrubner
The original article is here:

[http://wanderingbarque.com/nonintersecting/2006/11/15/the-s-...](http://wanderingbarque.com/nonintersecting/2006/11/15/the-
s-stands-for-simple/)

I am glad to see it get more attention. It is a classic and it is really about
more than SOAP. It is about the way technologies get hyped and over-sold and
over-promised, and then made unusably complicated. SOAP is just the example.

~~~
raganwald
_It is about the way technologies get hyped and over-sold and over-promised,
and then made unusably complicated._

In the excellent book "Antipatterns," I recall that this is called a "Wolf
Ticket:"

 _Wolf Ticket is a product that claims openness and conformance to standards
that have no enforceable meaning. The products are delivered with proprietary
interfaces that may vary significantly from the published standard._

<http://sourcemaking.com/antipatterns/wolf-ticket>

Wolf tickets are sold as safe choices because of their interoperability, but
of course once you have anything non-trivial built upon them, you discover
that the interoperability doesn't actually work and you are left locked into
your vendor.

------
jan_g
Must be ~5 years since I last used SOAP. Needless to say I hated the stuff.
Complex to build, complex to use (interoperability between different stacks -
java/.net/... - was like 'cross your fingers and hope for the best'), complex
to debug and walk through tcpdump network packets. It's complex in every way
but the name.

Of course, since that times I've alway advised against web services and so far
I've succeeded in avoiding them.

~~~
wizard_2
I'm being asked to create webservices so other developers don't do direct
database access and their stuff wont break when things change. How do you
manage that?

~~~
dansingerman
Designing an API is a skill in itself, but I think rule 1 is "Don't use SOAP"

JSON over REST seems to be flavour of the month FWIW.

~~~
roc
"Flavour of the month" might be a bit harsh. It certainly is popular these
days, so it's not wholly inappropriate. But it's worth noting JSON/REST is
popular with, and largely because of, people who've learned the painful
lessons of earlier messes like SOAP.

It's not (just) a hot new thing used by new faces who've never really known
any other way.

~~~
dansingerman
I actually didn't mean to disparage JSON over REST in any way. In fact I
really like it.

I only qualified the statement as technologies change quickly (only 12 months
age we would probably have been talking about XML over REST) and things will
no doubt change again.

------
chrisbroadfoot
My worst memory of SOAP was dealing with an attachments API that required each
_byte_ in a byte array to be wrapped in an XML element.

You ended up transferring ~10x the size of the file. I suppose gzip would have
helped somewhat.

~~~
ZoFreX
My worst memory of SOAP is using it. Experienced it for the first time ever a
couple of weeks ago (all I've used before now is ad-hoc JSON or XML apis,
mostly JSON) and (knocks on wood) never, ever again. The article touches on a
few of the things I really didn't like about it, the main one being the
expectation that you will use tooling to generate code rather than the
contract first, and that every time I hit a hurdle and switched to a different
library, I had to start over.

------
Jeema3000
I will now share my secret SOAP API Pro Method:

Step 1: Ignore all tools which supposedly make things easier (very important)

Step 2: Find the web service API documentation

Step 3: Ctrl-C example XML request

Step 4: Ctrl-V example XML request into program, replacing appropriate parts
with program variables

Step 5: Parse the response. You're on your own here... Godspeed. :)

~~~
Groxx
The company I work for has to digest a handful of XML and SOAP protocols.
Theoretically, they all conform to spec A or B, and/or define their own subset
of that spec with an XML language definition. There should be like 3 or 4
pieces of code which would handle _every_ format they offer.

Practically: ctrl-C, ctrl-V, and call them when it doesn't work. More often
than not it's either A) incorrect documentation, or B) you hit a bug (yes,
this means their sample-code doesn't work. It happens frequently). A good
chunk of our request-data builders are simply string manipulators, because
some of the APIs we call are nitpicky about the _order_ of XML attributes in a
tag.

I laugh when people tell me XML works better "because it's a standard".

------
ahupp
At one time SOAP wasn't too bad, until it tried to solve a lot of complicated
problems (via WS-*), and in the process made the simple problems complex.
Contrast this with HTTP which is being used for ever-more complex problems yet
is really no more complicated in the simple case than it was in 2000. This
seems like an important principle in protocol design.

~~~
pornel
Indeed. "RESTful" is basically a name for using HTTP well, and such APIs are
usable for anything from bash script to Big Vendor Library™.

------
colinloretz
I do a lot of Salesforce.com development and the use of SOAP has been the bane
of my existence. They have recently introduced a new REST API that will be
going GA in the spring.

"Dev: What happens if I GET the endpoint’s URL?

SG: Don’t know. Using GET is undefined.

Dev: Hrrm. And what happens if I move the service to a different endpoint? Do
I get a 301 back?

SG: No. SOAP doesn’t really use HTTP response codes.

Dev: So, when you said SOAP uses HTTP, what you meant to say is SOAP tunnels
over HTTP."

The beauty of REST is that it is representative of how the web works. With
SOAP you're almost always limited to the use of POST methods and when I go to
read another developer's code, I see their own defined nouns and verbs for
resources they are sending/receiving like "getUsers", "getContacts", and
"createPerson". These often are ambiguous or don't match up with the actual
resource they are trying to work with.

Endpoints in REST are self documenting, you can read what it is that you're
trying to do based on the endpoint and the HTTP verb (put, post, delete, et
al)

~~~
lanstein
From which language, out of curiosity?

~~~
colinloretz
Predominantly PHP and Ruby.

------
tomelders
I feel a bit sad for all those people who worked on SOAP. I assume most of
them simply wanted to make the web better and now we all point and laugh at
their efforts with the 20/20 vision that only hindsight can allow.

Thanks for trying SOAP people, it was a noble effort but it's game over I'm
afraid.... oh wait, I just saw on Wikipedia that these were Microsoft people.
In that case, screw em. SOAP is wank! YOU'VE WASTED YOUR LIVES!!

~~~
Ingaz
Even worse for CORBA. ..

On the second thought: The same companies made SOAP right after and along with
CORBA. Maybe, even the same people. Don't blame Microsoft too much: IBM,
Oracle, SAP, BEA - they are all ... equally "good"

------
orangecat
We have the misfortune of dealing with a third party SOAP API at my office. My
coworker did it the "correct" way, autogenerating thousands of lines of C#
from the WSDL and trying to get the objects transparently serialized and
deserialized. That turned out to be a multi-week effort, so finally I got fed
up and spent 4 hours writing code to directly extract the values we needed
from the raw XML.

~~~
vyrotek
I'm no fan of SOAP, but as a C# guy I'm curious to know what took so long?

~~~
silverbax88
I've got the same question. But I've written them in both Java and C#.

I worked on a project recently where we had a team of Java guys who worked on
a SOAP implementation for a month. They could not get it to work in any way,
shape or form. It was handed to me, and three of us did it a half an hour. All
custom SOAP, still worked.

I just don't comprehend why this seems so hard to people on Hacker News. SOAP
is just another protocol and as messy as any other.

~~~
steveklabnik
> SOAP is just another protocol and as messy as any other.

I think that's where you and most of the other people on the thread are losing
it. SOAP is way messier than just good old REST.

(disclaimer: I've never been forced to actually use SOAP.)

~~~
SoftwareMaven
I have had to do both: SOAP is WAY more messy.

------
dminor
I think it's a law that any protocol or technology with 'simple' in the name
invariably isn't.

~~~
cperciva
It's also a law that any field with the name 'science' in it isn't a science.
(Health science, social science, military science, earth science, computer
science...)

~~~
lsd5you
And any country with democratic or people's in it's name, is not democratic or
belonging to the people (Democratic Republic of North Korea, of Congo, PRC ...
)

------
grnknight
Wow. This sums up my entire exposure to SOAP over the last few months. Thanks
for the humorous, yet factual exchange of information!

------
st3fan
SOAP really just exists to keep a tools/consulting/appserver/softwarestack
business alive. Pretty sad.

------
bockris
Reminds me of the "Why I hate frameworks" essay by Benji Smith.

<http://benjismith.net/index.php/2005/09/30/hate-frameworks/>

------
aidenn0
SOAP has always seemed bizarre to me. It's something like "We think CORBA was
a good idea, but they messed some stuff up, so we'll toss the entirety of
CORBA and make something with a completely new set of problems while
completely ignoring most of the mistakes we learned with CORBA."

I'm still luke-warm at best on the whole ORB idea as-is, but even thinking
from the point of view of someone who thinks object brokers are the best thing
since sliced bread, I feel like the SOAP people got it very wrong.

------
dedward
It crosses some layer boundaries too.... having to manually edit (or I guess
dynamically generate) wsdl files so that we can add a reverse proxy or load
balancer in front of a webservice machine to access it several different ways
in .net was definitely a pain in the butt.

------
RyanMcGreal
This wonderful Socratic dialogue has articulated my professional hell over the
past six months.

------
Aaronontheweb
The only thing I like about SOAP's modern implementation is that it comes
packaged with a WSDL usually - I would welcome a world where most REST APIs
included a WSDL so I could just automatically stub a wrapper library.

------
erikstarck
Design-by-committee in action...

------
otoburb
Some previously implemented projects implemented a SOAP prepaid account
balance billing interface that runs in production today. Nobody is willing to
touch the interface for modifications because every developer tasked to review
proposed changes complain that it's way too brittle and prone to complexity.

This article is bittersweet because it sums up everybody's feelings pre- and
post- implementation.

------
naba
Sigh. this article made me a little sad. I keep wondering why the corporates
who have all the money and resources keep using a technology that is just so
old and has so many issues, when they have the better alternatives. My entire
week was spent in just trying to get the configuration and a hello world
service up and running.

------
ph33t
Let me preface this by saying I'm not particularly a microsoft basher, however
this smacks of their history of interface development. Remember COM in the
90's? It was so complicated no one really knew how it worked. The only way to
use it was to use a compiler that had native support for it ... MS Visual
Studio and MS VB. Delphi came a long way quickly and made it work. Anyway
whether intended or not, the result was you were initially tied to using a MS
tool to use the technology. SOAP seems the same. Odds are if you're writing
one end of it or another (client or server) somewhere the mix you're going to
have a Microsoft tool. If you want to talk to the product of that Microsoft
tool by far the easiest way will be to use a Microsoft tool. So despite being
"open", their implementation of it ties you into some vendor-specific tools.

------
mike-cardwell
Eurgh. Reminds me of writing Perl code to talk to .NET SOAP services in a
previous job. Never again.

------
bediger
Why did SOAP win, and XMLRPC not win?

~~~
wiredfool
Soap was supposed to be the enterprisey safe superset of XML-RPC.

From my experience back at the beginning -- XML-RPC was slightly
underspecified, and would have used a bit more of a firm hand about
clarification of what was legal and what wasn't. SOAP was wildly overspecified
and complexified to the point that you needed an army of consultants. Which is
just perfect for enterprisey stuff, since you conviently have an army of
consultants that need to have something to do.

IMHO, XMLRPC inhabited a middle ground that was washed away by REST and
ajax/json type interfaces. It's an extra bit of complexity that's just not all
that popular now, rather than a stunningly less complicated version of SOAP.

~~~
spolsky
Yep... as I remember it, XML RPC was "specified" by Dave Winer, and it was
really sloppy. As I remember, there was no discussion of character encoding in
the spec, and if you read the spec literally, you actually HAD to generate
invalid XML documents because the spec was written by someone who did not
understand that there was such a thing as character encoding and that it was
important. And Winer absolutely refused to add features or to allow any kind
of process by which XML-RPC could evolve into something good enough to use.
Then the Microsoft people who brought you COM in all its baroque loveliness
got their hands on the concept and made an industrial strength, godforsaken,
complex thing called SOAP. The problem with SOAP mostly stemmed from the fact
that they thought that all the work would be done by compilers and IDEs and so
forth... they thought all the programmer would do is click a button and hey
presto they would be able to run one object on one server and another object
on a second server, and who cares what happens on the wire protocol? It's the
compiler's job! But that's a terrible recipe for interoperability.

------
ojbyrne
The "Simple" in SOAP is seriously overtrumped by the "Simple" in SNMP.

~~~
Luyt
...and the 'Lightweight' in LDAP ;-)

~~~
Groxx
Oh God, I started reading the spec for LDAP a while back... terrifying.

------
Confusion
It's easy to rant, but hard to come up with a viable alternative, that
encompasses the same scope. XML-schema and WSDL are mocked as an aside, but I
dare you to provide me a REST alternative for those, as standardized as those.
For all the horror stories, I have used Java to interact with a C# webservice
without any pain, including WS-Adressing. The WSDL and XML-schema were a
godsend compared to the earlier spec.

Like people that think you can just replace XML with JSON: you are missing
stuff.

~~~
rue
A REST alternative for what?

------
iwwr
Could it be that SOAP never had a solid set of test cases? Implementing a
reasonably complex API should involve passing a series of public and very
specific tests.

------
Rabidgremlin
Love it. However at least SOAP is a spec and generally works.

REST is an architectural style there is no spec, just a idea! Added to that
most folk also only build REST-like services.

Implementing a client for REST based services often requires a bunch of
(generally simple) coding which takes time and is error prone.

Also pure REST is really good for building data access/CRUD services but makes
it hard to build RPC type services without mangling the semantics.

~~~
generalk
> However at least SOAP is a spec and generally works.

SOAP has several versions of the spec and a bunch of vendor-specific cruft.
The SOAP use-cases from this comment thread are enough indication of that.

> REST is an architectural style there is no spec, just a idea!

Yeah, but you use REST every day in your web browser. A lot of the times it
isn't strongly RESTful, but it's still REST. For example, to view this comment
thread and post your reply to someone's comment.

In SOAP, if I call the getUserByID(42) method on your end, and you don't have
a user with id 42, what do you do? Do you return an empty response? Do you
return some kind of SOAPFault? If so, what kind?

In REST, if I GET <http://yourservice.com/users/42> and you don't have user
42, I get HTTP 404. That's the only logical response.

> Implementing a client for REST based services often requires a bunch of
> (generally simple) coding which takes time and is error prone.

This is no different from SOAP, with the exception that with SOAP you have to
have your requests stuffed into XML by some libraries which have read some
other autogenerated XML to figure out how to stuff your requests.

With REST, you can write a library (that wraps HTTP calls), or you can use
curl, or (for simple GET requests) you can use your browser. Your platform
might not support SOAP, but it definitely supports REST.

> Also pure REST is really good for building data access/CRUD services but
> makes it hard to build RPC type services without mangling the semantics.

This has been said multiple times but let's say it again:

 _REST is not RPC._

If you're looking to remotely call procedures on your app, REST isn't going to
provide that.

The only case where REST doesn't work is the case where your client demands
SOAP. In any other case, REST works beautifully. Not everyone does REST right,
but even when it's done suboptimally (e.g. not providing hyperlinks to related
resources) it's still worlds better than SOAP.

------
motters
I never did anything using SOAP, and thought that this technology died many
years ago.

------
MarkMc
"I trust that the guys who wrote this have been shot."

Ha ha! I must remember this put-down - it could be used in so many contexts :)

------
nervechannel
As an ex-SOAP-dev... Yeah.

------
mcherm
Oh god... that's my life!

------
yogipatel
I stopped using SOAP in the shower a month ago and have never felt cleaner.
Showering is a more efficient process now:

\- I spend less money on resources (SOAP, lotion, etc)

\- I get clean faster -- SOAP used to slow me down

\- Using someone else's shower is easy, I just take my towel. I don't have to
worry if their SOAP is compatible with me.

