Saturday, July 03, 2004

SOAP vs. XML-RPC vs. REST

I covered SOAP, XML-RPC, and REST in my last book ("Java 10-Minute Solutions") - really, I like all three schemes for implementing data transfer over HTTP (I only use HTTP transport for SOAP, although other transport mechanisms like SMTP are also possible).

Mostly because of the wealth of free infrastructure software, I just about always do server side development using Java. However, I am also a huge Lisp enthusiast (I wrote 2 Springer-Verlag Lisp books a long while ago, and have enjoyed Lisp since the late 1970s). Although Smalltalk (for me) comes in a close second, I just prefer Common Lisp over other programming languages for algorithm development and research programming.

Usually, once I have figured out how to solve a problem, it is easy to re-write in Java. Generally, this is a good solution because like it or not, Java is becoming a universal language. However, sometimes I just like to leave research code in Lisp.

Enter my thoughts on SOAP, XML-RPC, and REST: except for the rather expensive Franz Lisp (which I have a free long term non-commercial use license for), SOAP support is not so good in the Common Lisp world.

The situation is much better with XML-RPC: Sven Van Caekenberghe has written a very nice light weight XML and XML-RPC package that is reasonably portable.

Even simpler is to use REST. I spend a few minutes hacking an old Common Lisp HTTP server program this morning to add POST support. Not too difficult as long as the binary data is not a special MIME type.

Then, I stepped back even farther, and wondered why not to just use REST with HTTP GET, as I have done in the past. The advantage is that it is trivial for client programs written in any language to send an HTTP GET request over a socket connection (just need to escape special characters). For practical purposes there is no real size limitation for passing data.

BTW, if you are not familiar with it, REST supports sending functional-call type requests over HTTP, with the return value being an XML payload that the client is presumed to understand. This is not as tidy as SOAP with WSDL support, for sure, but much lighter weight.

No comments: