About SOAP vs REST vs XML-RPC, Dave writes:

By and large REST interfaces don't tell you how to serialize and deserialize complex structures, so you kind of start from scratch every time. If they use a SOAP encoding, you get some of that. But there just is nothing simpler than saying "Here's the XML-RPC interface, and some sample code in a few of the popular scripting languages." If you want developers to get going quickly, avoid the religious wars, just support XML-RPC. Now even this isn't bluster-free. Think of it as evangelism. Have a nice day.
Though I don't like his remarks on REST, I gotta give Dave an amen here and thank him for having XmlRpc out there for me to stumble upon. REST seems shiny and neat to me but incomplete - I'm pulling for it because it seems warm and fuzzy to my ivory tower branes. SOAP seems to try to be nice & clean, but feels grungy and toxic to me and I've always felt a vague sense of unease when walking past its house on the block. In the middle, XmlRpc seems to be the right balance of dirt and acidity to grow things in.

About XmlRpc, I can speak with some experience now. I first started tinkering with it a few months shy of a year ago, when I first launched this blog. I went to http://www.xmlrpc.com and learned it in less than an afternoon. Cobbled together a few Projects with it, and saw an opportunity to introduce XmlRpc as a new tech at work.

(In case you don't know about my job, I'm the guy who does most of the research & development, tool building, and overall platform architecture at a promotions company called ePrize. I grumble about the place from time to time, but on the whole they let me do an amazing amount of wandering around in finding new things.)

Anyway, we'd been poking around with a few different means of integrating our promotions into clients' websites. You see, we host the web part of all promotions on our servers, and work toward making inclusion of those promotions not much harder than slipping in a banner. But sometimes, there's just no avoiding more complex integration. And sometimes, it's exactly what you want with things like shared sign-up & login, awarding tokens & coupons, and coordinating between vendors' services. So, we had a few different REST-esque URL-based schemes, some FTP-and-PGP-based things, and even managed to convince one client to use a one-off protocol between two perl net daemons. Every time, it was something new, and we could seem to get no two clients happy with the same integration scheme.

Then one day I bring XmlRpc into the office, and weave it into our app platform at the ground floor. Overnight, just about every aspect of every promotion we do can be accessed via XmlRpc, given the proper switches thrown and the right access controls set. Producing an XmlRpc API spec for potential clients took mostly a bit of cut & paste massaging of our internal API docs.

(Your mileage may vary greatly, but our homegrown platform seemed pre-designed to fit with XmlRpc. This point right here may be what makes this anecdote fall on its face for you and your experiences. But, based on the success we have with it on the client end of things, I suspect that we're not that much an outlier.)

The next day, we had a meeting with a giant customer whose name I'm not sure I can mention, but suffice it to say you've heard of them and It's very, very likely that you've used their gadgets. We helped them put together a customer referral and rewards program, using XmlRpc as the glue between an online store vendor, the client's site, and us. It was a great success, and since then we've done another dozen or so cool promotions involving XmlRpc.

What makes this tech so successful here is that it's so simple and decently understood. I get it, my boss gets it, his boss gets it, the sales guys get it, and the marketing guy who's always our first contact at a client gets it. And when we finally drill down to a tech guy on the client's side, we just tell him, "Here's the API for your promotion, and visit http://www.xmlrpc.com for details on how to call it." And that's it - 75% of the time they get it and implement it. The rest of the time, we have to spend some time proving the tech and answering doubts, but it's always a pleasant experience from our end having all the answers.

I'll adore REST if/when it gets to this point in helping me get mine and my client counterparts' jobs done.

Anyway, this is sounding like a bad infomercial and I need to get back to work. But I had to toss out this bit of anecdotal dross in favor of XmlRpc.


Archived Comments

  • ...unless your client is in China and oops, Dave forgot to mention that since Radio can't do Unicode, the XmlRpc spec only uses ASCII strings. (also oops for Russia, Africa, Arabia (ok, you guys gonna throw bombs at them anyway) and all others who sometimes use non-american characters). Damn, then. That's why non-american companies tend to use SOAP. If XmlRpc (and most implementations) would not unnecessarily exclude 2+ byte characters, which have been specified in the XML-spec (XML is Unicode) by the way, it would be fine. I can't sell an API for hotels in a country where my software can't spell the name of a customer... "does your name have an english spelling, sir?"
  • Well you can just go ahead and use XmlRpc and UTF-8 encode your unicode strings. Which might be a technical violation of the spec but seems to work well enough in practice. Or encode strings as int arrays containing unicode characters?
  • I'd like to build XmlRpc server functionallity into an application we have, but can't find a c++ server library that works under windows (as opposed to unix). Does anyone know of one, or will I have to do it miyself it I want this?
  • I've posted some thoughts: http://www.blogstream.com/pauls/1038403139
  • I was about to say that the Unicode issue hasn't been one for us, because we don't really have anything for human consumption in our APIs. That is, no presentation strings or words or sentences. But then I had to think about that - we do simple shared sign-up & login via XML-RPC. If we had to do such a promotion globally, we might have problems with login names and passwords. I'm sure there're more landmines awaiting my feet.
  • While Unicode in XML-RPC is surely an issue of original specification, that is not a practical one as most implementations never bother to enforce that limitation (why limit it when underlying XML processor allows _any_ charset encoding?). Now, regarding REST and XML-RPC, I too agree that Dave's comment on REST was bit off. OTOH, I think I can understand why he sees XML-RPC based design is more appropriate (for his goal) than REST-style design. While REST focuses on defining set of accessible resources, XML-RPC focuses on defining set of callable interfaces. Traditional programming is about "programming by contract", and in many languages, that means defining set of interfaces (API). Many developers are just so much trained to have this API-centric world view, and adopting REST means there's a need to tweak their heads a little. I think it could be argued that this use of "set of resources" is almost same as using multiple objects in OO language. Whole service is constructed by interaction of multiple live objects (resources), and each object (resource) has set of interfaces to be called. I believe REST principle requires you to break up service into smaller set of objects until eash object only needs to implement minimal set of standard interface. But what's puzzling me right now is the way to "expose" selected micro-objects as URI-addressable resource. This is probably more of a problem of toolkit implementation, but it's currently just awkward to me. Unless RESTful implementation brings easy way to do it, XML-RPC will be understood *much* faster by developers than REST-style programming model. I'm wondering if this is going to be a typical "worse-is-better" case.