SOAP strategies

[Paul Boddie]

On 19 Feb, 16:59, Paul Watson <paul.hermeneu... at gmail.com> wrote:
>
> Have I offended?  My apologies if I have.  I thought I showed that I had
> done some homework and used Google and did the other things to show that
> I was willing to put forth some effort.  Please tell me if I have missed
> something.  If I should look somewhere besides Python for doing SOAP,
> then please say that also.  Thanks.

There's a Wiki page here about Web services in Python:

http://wiki.python.org/moin/WebServices

I don't think that there's been a great deal of visible activity
around SOAP in the Python community other than that you've already
noticed. I entertained the idea of doing some more complete SOAP
support as an add-on to the libxml2dom project, but not wanting to
implement all the related specifications (schemas, service
descriptions), I struggle to see the benefit compared to simpler
solutions.

That's not to say that SOAP has no value. Clearly, if you consider the
different "use cases", SOAP is probably more appropriate for some than
other solutions would be. If one were exposing some kind of repository
through some kind of Web service, I'd consider approaches like REST,
along with technologies like WebDAV (which overlaps with REST), XML-
RPC and SOAP. But if the Web service were to involve issuing
relatively complicated queries, and/or the repository wasn't strictly
hierarchical (or couldn't be elegantly represented in such a way),
then it would arguably be less appropriate to deploy a "pure" REST
solution, favouring XML-RPC and SOAP instead.

What undermines SOAP for me is that if I'm not too interested in
treating it like some kind of RPC mechanism, then I can get most of
the pertinent benefits from exchanging plain XML documents. You can,
of course, do SOAP like this, but the obligation to look after the
boilerplate elements (which should permit lots of fancy features like
"routing", if such stuff is actually used in the real world) seems
like a distraction to me.

Paul