XML-RPC, a mini case study
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.
shortname=oooccb
Archived Comments