May 18, 2003
ReST vs XML-RPC
While "we":http://outerthought.org/ are often trying to advocate ReSTy interfaces, like we did for xReporter to an extensive degree, and strongly believe one doesn't need the arty-farty descriptors of WSDL, or the gee-we-need-yet-another-type-system-worldview of SOAP, I do often worry about the market adoption of our ReSTy belief. I'm not talking about business market adoption, but about whether these ReSTy resources do find customers.
JSPWiki offers an XML-RPC interface. Python has several permutations of an XML-RPC client (and server) library. I get to hack together a Wiki diff notification mail service over the weekend, being utterly clueless in general, and about programming specifically. The XML-RPC library offers sensible objects and methods I'm capable of immediatelly using in my application. Even though I know XML-RPC is utterly uncool because of its narrow-mindedness in encoding support, and the severily limited amount of (sometimes strange) types, I was pretty happy consuming JSPWiki's XML-RPC interface and build a client app for it. Also, a huge amount of weblogging client apps seem to exist, all talking that Weblogging API to Movable Type, Radio, and whatnot. Arguably, this doesn't prove anything more than _XML-RPC was there first so everybody started using it_, but maybe there was some sense in it of _it's simple and easy-going, so we could as well use that 'standard' instead of inventing our own protocol_.
Enter ReST, which of course cannot be compared with XML-RPC, since it is only an _architectural style_, and not so much something actually useful for mere humans (pun intended). Offering ReST services seems easy, if you spend some serious thinking on naming your resources and making the GET vs POST deliberation. ReST's ease for deploying resources seems to support the fact that many more business connect through ReST rather than SOAP to Amazon's B2B back-end (overheard somewhere).
When thinking about consuming a ReST service however, I always start to worry about the amount of extra, lowlevel XML2nativeobject code I will need to write. I worry about the fact that my client will need to be smarter, that it will need to parse responses to find the URI of the next resource to be invoked in the application flow, and that, contrary to the braindead XML-RPC world, each server will have its own client library.
Even though ReST and XML-RPC compare like apples and oranges, I start to wonder when somebody will write a ReST client library.