
Please drop the SOAP - thecoffman
http://thecoffman.com/2011/01/please-drop-the-soap/
======
rst
One of the things in life I really regret is suggesting SOAP on a project. I
thought it was just a packaged, somewhat elaborated version of a semi-
reasonable XML-RPC type thing --- and worse, that the idea that it was
standardized meant that you could count on some kind of half-decent
interoperability.

It was initially sold that way, but that was just the first of a parade of
sales pitches, hilariously chronicled here,
[http://wanderingbarque.com/nonintersecting/2006/11/15/the-s-...](http://wanderingbarque.com/nonintersecting/2006/11/15/the-
s-stands-for-simple/) \--- endlessly shifting as if seen through a fun-house
mirror.

------
asmithmd1
SOAP is a nightmare.

soapUI is an application that will let you fiddle around until you get the
calls right.

I recently did exactly this. I wound up not only generating the SOAP envelope
by hand but also the HTTP headers:

SOAPAction: "<http://...//SubmitDataform>

What is the action I am trying to do doing in the HTTP headers?

~~~
pak
You Are Doing It Wrong.

Anybody that tries to interface with a SOAP interface by writing envelopes by
hand is wasting their time and half-implementing the (long, terrible,
complicated, blah blah) spec.

Find a good toolkit. Yes, the protocol is way over engineered but good tools
can and do abstract that all from you. For instance, PHP's standard library
lets you plug in a WSDL URL and consume SOAP services in two lines of code.
(And because it is a good toolkit, it lets you spit out all traffic with one
debug flag, unlike whatever terrible thing the author of this article is
using.)

Most of what people complain about in these comments would be moot with good
tools. You would probably complain about REST if you didn't have curl or
Firebug and had to telnet all your test calls--that's equivalent to what most
people here seem to be doing.

~~~
route66
I don't know what wsdl's you were dealing with, but I met a fair amount of
them who were not consumable by neither php-soap, python and even a java
client while trying to read a .net one.

The reason people are writing their own envelopes in cases (like I did also)
is because the tooling is not delivering up to it's promises. (Let alone that
the server might not even understand the two-line-code genertated nusoap
reponse because he interpretes some ws-* rules about namespaces differently.

The conclusion is: nobody wants to write his/her own envelopes.

~~~
kaylarose
Every time I here about regular Soap clients failing, it's _always_ in regard
to trying to consume a .NET service.

I don't know anything about .NET, but I wonder if there is something
profoundly different that is going on behind the scenes, or does it just
generate crufty WSDLs? Can anyone shine more light on this?

~~~
route66
My problems were in fact with Java web services. There are different
interpretations possible of the recent SOAP standards (or non-standards, as
some are more de-facto than ratified) of smaal details as where to put type-
info in the wsdl and if it is allowed to be redundant. This way sensible
tooling is defied. Serving and consuming smaller services with light messages
and shallow structure works mostly out of the box.

The going gets rough when people put half their strongly typed domain logic in
the wsdl which has to be recereated on the other side. Hint: Collections !=
Arrays != Hashes

So, problaby not .NET but bloat related. Interoperability is a problem on all
sides though.

------
kleinsch
Debugging SOAP stuff is a complete nightmare, but trying to figure out and
implement somebody's RESTful API that has 100 different types of objects is
also a hassle, since there isn't code generation that can help you.

For tiny one-API-call tasks, I'd much rather use a JSON REST API that I
completely understand. When I'm trying to interface with a complicated system
that has a million different objects, I'd rather spend an hour figuring out
the tools, then rely on generated code so I can take advantage of IDE auto-
completion instead of digging through the documentation to remember the params
and return value. It's the in-between of these two cases that's the devil,
especially since big nasty APIs always start out small and simple.

------
zakovyrya
I'm pretty sure everybody read this piece:
<http://harmful.cat-v.org/software/xml/soap/simple>

------
regularfry
Urgh. I had exactly this experience trying to get the Exchange Web Services
API to work. That's worse, because the author's solution, dropping any
pretense at using a notionally "pluggable" API and just debugging with
Wireshark, won't fly over HTTPS.

~~~
mariusmg
Try it with Fiddler.Should work fine over https.

~~~
regularfry
No Windows boxes round these parts, or I would have. I tried WebScarab, but
without the server certificate it was a lost cause (unless I missed a trick
somewhere).

~~~
lmz
You have to generate a certificate for the proxy (WebScarab) and have the
client trust it. The proxy will then act as a man-in-the-middle, presenting
its own certificate to the client. See:

[http://www.owasp.org/index.php/Generating_Custom_SSL_Certifi...](http://www.owasp.org/index.php/Generating_Custom_SSL_Certificates_for_WebScarab)

~~~
regularfry
Now I know what to do if I ever find myself in that situation again. Thanks.

------
wdewind
People still use SOAP? Yikes, sorry.

~~~
thecoffman
Sad part is its not just "People" Google's AdWords and Microsoft's AdCenter
are both SOAP. Par for the course from Microsoft, but I'd expect better from
Google.

~~~
nailer
Yeah, I have to work with the AdWords API and it sucks just as badly - the
documentation also lags behind the implementation too.

The super annoying thing is worrying about WSDL, XML namespaces and xpath for
something as simple as getting a count of alerts.

~~~
robryan
Their client library is decent, for PHP anyway so you mostly get SOAP
abstracted away. Up until you get an error then the usual problems are there.
The underlying code in the client library is super bloated though, like what
you would imagine from visual studio endpoint type stuff in the article. It
may be that the core adwords developers are using Java and an old school SOAP
interface makes sense to them. They certainly had a chance to change it
recently with the new version.

~~~
nailer
in Python, they make you chose between ZSI and a beta soappy release. Their
site has a getting started video which mentions running a config script they
no longer distribute. most docs are using a different module name. Oauth isn't
implemented at all.

In JS, you have no client library so you're required to roll everything from
scratch.

PHP has oauth, more demo code and better docs, I've recently been using it to
build a JS lib for a work project.

The thing is, rather than maintain one client library, half maintain two
others, and have a bunch of unofficial libraries, if they just made and
documented a REST interface everyones lives would be easier.

~~~
robryan
Yeah, unfortunately I don't think it has a lot to do with the guys who have
maintained the client library, I think they would agree.

Big problem is at the moment that PHP has Oauth for pretty much everything
except report downloading, which is essentially separate from the rest of the
API.

Hoping they fix this before I launch, as most of the good of OAuth is negated
if I still have to collect a username and password for report downloading.

------
shimi
Soap isn't really good, but its not just MS who pushed it. In the 90s it was
endorsed by giants like IBM and Oracle

~~~
thecoffman
Completely right - its not a Microsoft problem as much as its an "enterprise"
problem. IT Managers love things like SOAP.

~~~
pak
And they should. It's easy to turn a WSDL into an exhibit for a contract,
because it is a description of an API that can be converted to human readable
and machine readable formats. There is no equivalent for REST, and most REST
services have a loose interpretation of what it means to be "RESTful". Try
doing serious, paid-availability integration with REST and watch the managers
tear out their hair and the lawyers weep.

------
praptak
Not that I'm a big SOAP fan, but the author seems to be seriously confused:

 _"For starters you have to point Visual Studio (sigh) to the service
reference, at which point nine thousand (yes, that’s nine-zero-zero-zero)
lines of code are generated."_

 _"Not a descriptive error, or an HTTP status code, or anything that could be
used to track down the problem but a “SOAP Error.”"_

 _"Long story short, in order to inspect SOAP messages you have to write a
class that implements the ICLientMessageInspector interface."_

These are supposed to be problems with SOAP? To me they look like a crappy
implementation.

The conclusion is also crappy:

"In my mind SOAP’s biggest failure is what some people consider to be its
biggest success – it abstracts away all notion of the underlying HTTP model
and replaces it with crutches like code generation."

Jeez, man - SOAP has problems, but _code generation_!? It's not a problem with
SOAP but with the way your environment integrates with SOAP. Code generation
over _any_ protocol would create the same problems and there's nothing about
SOAP that makes code gen inevitable.

------
ericmsimons
I have to say, REST is just a lot more straightforward than SOAP. Although
there are numerous advantages with SOAP, I always cry myself to sleep at night
when I find out that I have to use a SOAP API to complete a part of a project.

------
mariusmg
Actually the guy is actually complaining about consuming a WS from WCF
(important distinction because consuming it using the default WS stack from
.NET is a much better experience). Besides that...carry on praising REST.

------
y0ghur7_xxx
It was just a bad SOAP api. You can write a bad and cumbersome REST api as
well if you want, and MS would certainly be capable of doing so. SOAP is not
really the problem here.

~~~
regularfry
SOAP _is_ the problem here. Specifically, it's the architectural decision to
hide the protocol details which inevitably ends up biting everyone who uses
it, because it's a textbook leaky abstraction.

~~~
y0ghur7_xxx
"Specifically, it's the architectural decision to hide the protocol details
which inevitably ends up biting everyone who uses it"

Sorry I don't agree.

Firefox for example hides the protocol details. You don't need to know DNS,
TCP/IP, HTTP to browse the web.

It's the same for SOAP. If with "hide the protocol details" you refer to this
part of the post

"I got an error. Not a descriptive error, or an HTTP status code, or anything
that could be used to track down the problem but a “SOAP Error.”"

you may not be aware that the SOAP specification has SOAP exceptions. And they
are actually quite easy:

<soap:Fault>

    
    
      <faultcode>soap:Client</faultcode>
    
      <faultstring>Please specify your birth date</faultstring>
    

</soap:Fault>

He just used a bad SOAP api that returned an useless error.

There are many other things about SOAP we can hate and that need to be fixed,
but in this particular case SOAP is not at fault, and REST could very well be
exactly as bad.

~~~
regularfry
> Sorry I don't agree.

> Firefox for example hides the protocol details. You don't need to know DNS,
> TCP/IP, HTTP to browse the web.

I don't think that example supports your argument. Quite the reverse, in fact.
Firefox doesn't hide that much of the details. You can still see the gory
details of URLs and HTTP requests surfaced quite clearly, and the experience
of using the web is that much richer if you know what they are and how to
manipulate them. Firefox doesn't actively prevent you from doing so if you
want to, which it would if it was trying to present a sealed abstraction.

As regards errors and error reporting, I don't particularly want to get into
REST v SOAP, because that's tired ground that's been trodden a thousand times
over. However, REST has an advantage over SOAP here in that it uses HTTP error
codes. An app which returned a 200 response when it couldn't find something
would never be described as RESTful, whereas a SOAP app can get away with
_anything_ as an error response. It's simply not possible for a REST API to be
bad in that sense where it demonstrably is for SOAP.

~~~
Waywocket
>Firefox doesn't hide that much of the details. You can still see the gory
details of URLs and HTTP requests surfaced quite clearly, and the experience
of using the web is that much richer if you know what they are and how to
manipulate them. Firefox doesn't actively prevent you from doing so if you
want to, which it would if it was trying to present a sealed abstraction.

Contrast with IEs 'friendly' error messages by default. Instead of an easily
diagnosed 'page not found', or 'address not found', or 'server error' you get
'something went wrong' and then a list of _always_ incorrect guesses as to
what the problem might be and a confusing list of irrelevant things you can
try to 'fix' the problem. I bet somebody got a bonus for that feature.

------
route66
To give a slightly different spin to the discussion: does REST solve some of
the problems SOAP addresses? First there was REST, now closely related to
HATEOAS... I see the acronyms are coming.

How to discover the meaning of data in the absence of a WSDL/RESTDL? Will we
have microformats with links pointing to ontology-servers? Wat if its JSON?

I wonder what REST looks like five years from now, when for instance, IBM and
M$ become involved in a standardization process ...

------
koevet
I don't like Soap for the same reasons everyone hates it. Having said that, in
the Java space there are plenty of tools that turn the Soap experience into a
bearable one. With CXF, for instance, is quite trivial to generate client code
out of a WSDL file. The generator binds the request/response payload to Java
beans so the developer doesn't have to understand the intricacies of the
protocol. Debugging is also simple.

------
mark_l_watson
Diss on SOAP if you want but it does provide good error support for working
with transactions in Java EE 6, ESB, etc. If you need to use infrastructure
that works with SOAP, then use SOAP and stop whining.

If you don't need to interop with existing systems that use SOAP, then sure, a
REST style makes sense.

~~~
iramiller
Since the op is using WCF for calling the web service he would have a much
easier time figuring out what is going on if he turned on WCF tracing. Every
step in the pipeline including the messages sent on the wire and timings are
available.

Once you know the secret platform handshake these enterprise tools are pretty
easy.

Edit: fix annoying iOS auto-correction.

------
MindTwister
SOAP in visual studio might be a pain, but its really not that difficult when
working in PHP:

<http://php.net/manual/en/book.soap.php>

I've implemented both servers and clients using SOAP with low to no hassles.

    
    
        Bad implementation != bad spec

------
thecoffman
edit: appears to be back and working fine.

Embarrassing - despite my best efforts it appears as if my little linode
couldn't handle being frontpaged - here's a cached entry for now:

[http://webcache.googleusercontent.com/search?q=cache:UehgGNU...](http://webcache.googleusercontent.com/search?q=cache:UehgGNUoeqUJ:thecoffman.com/2011/01/please-
drop-the-soap/+http://thecoffman.com/2011/01/please-drop-the-
soap/&cd=1&hl=en&ct=clnk&gl=us&source=www.google.com)

The blog entry is cached as a static page hourly and served via nginx as such
- this load shouldn't have killed it. Will be interesting to dive into.

------
KevBurnsJr
LOL, Wireshark. Nice.

