[Cialug] how are you implementing "web services"

[Colin Burnett]

If I have to use SOAP or XML-RPC, I pick XML-RPC.  IMHO, SOAP is
bloated and overly complex so I stay away.  NuSOAP for PHP vs. SOAPpy
for python is like night and day, respectively.  Though python has a
significant advantage (in terms of coding simplicity) by having
first-class functions.  Setting up a client or server with SOAPpy is
like 2 lines.

That said I ran into a severe hinderance with XML-RPC a month or two
ago: array keys must be strings.  That puts a real buzzkill in python
since dict keys in python can be any immutable data type: int, bool,
str, tuple, etc.  So I ended up writing my own RPC layer using pickle
and runs over HTTP.  Calling server.list.of.a.dotted.object.path(...)
yields

{'args': [], 'kargs': {}, 'name': ['list', 'of', 'a', 'dotted',
'object', 'path']}

which is pickle'd on the client and un'pickle'd on the server, which
allows unnamed and named arguments on nested objects.  (Server
response is something similar and traps exceptions.)

I haven't done any benchmarks but I suspect pickle (or cpickle even)
is much (*MUCH*!) faster than the XML parsing and generation that
XML-RPC and SOAP require.  Especially SOAP.  Not only that but it
opens up for serialization of many objects that I honestly have no
clue if XML-RPC or SOAP can handle (notably datetime.datetime and
exception objects).  Serializing exception instances (and the entire
server-side backtrace for debugging) is just as trivial and re-raising
them on the client is equally trivial.

Regarding authentication.  Since it's over HTTP I have the option of
HTTPS as well as basic authentication and cookies.  I prefer cookies
over HTTPS.  You could do all of this with SOAP and XML-RPC if your
libraries are capable (or you write it yourself) and uses HTTP for
transport.  Otherwise you could pass some kind of session key on every
RPC call as a parameter, but if you follow the OSI model then this
blatantly mixes session with application layer and just makes for more
work in the end.

Caveat emptor: this is an internal solution and I haven't spent any
time considering the exposure of a pickle-based RPC service nor
needing client-access from anything but python.


Colin

On Dec 7, 2007 1:59 PM, Matthew Nuzum <newz at bearfruit.org> wrote:
> If you've written software that exposes an externally accessible API (either
> public or for your own consumption) how are you doing it?
>
> I've used soap and xmlrpc, and between the two I'm starting to prefer the
> simplicity of xmlrpc. However there's now REST, atom and other web 2.0
> solutions.
>
> What do you recommend when you're talking to other people about webservices?
> (please note the platform, since java people and perl people (if you can
> call them that) might suggest diff solutions) Also, I'm interested in how
> you're dealing with authentication.
>
> I'm about to rewrite some code that provides a soap based interface. I'm not
> sure soap is the best way, since it's been a thorn in my side since the
> beginning. Especially testing. :-P
>
>  --
> Matthew Nuzum
> newz2000 on freenode