XML-RPC SOAP REST JSON-RPC in 2012.
The battle contenders:
- XML-RPC
- SOAP
- REST
- JSON-RPC
It is the year 2012.
It appears to me that this is what the reputations are like:
Technology General Opinion Lion's Opinion Difference
============ ================= ============== ===================
XML-RPC 0 (neutral) +++ (great) undervalued
SOAP --- (evil!) --- (evil!) valued correctly
REST +++ (great!) ++ (good) slightly overvalued
JSON-RPC ++ (wow!) + (ok) slightly overvalued
It is the year 2012.
One of the questions people asked over and over, when comparing REST & XML-RPC, is this: "What's XML-RPC have that REST doesn't?"
Q: What does XML-RPC have that REST Doesn't?
Here's my answer:
A: Primitive typed data transported effortlessly.
When you use XML-RPC, you basically get a wormhole from one environment to another. The data types (numbers, lists, strings, dictionaries,) all transfer seamlessly. XML-RPC takes care of encoding the data types, and then un-encoding the data types.
When you use REST, you have to define an XML structure for encoding your data, and then you have to define another XML structure for receiving your response.
But with XML-RPC, you don't have to do either of those things. Because this is what you have with XML-RPC that REST doesn't have.
So stop asking that question!
REST & XML-RPC: Different Purposes.
- XML-RPC gives you native function calls across the Internet.
- REST gives you data structures across the Internet.
Native Function Calls are Fine.
There is nothing wrong at all with using native function calls.
I have heard REST people argue on esoteric lines that we should only be using data structures and "representational state transfer" and such gobbledygook.
Nonsense; There are plenty of great times when you just want a simple API that just works.
And that's what I've encountered so far with XML-RPC: simple APIs that just work.
It takes near zero effort at all to set them up and make them work, on both the server and the client sides.
I work with service APIs all the time. Sadly, they are in SOAP. So many times, I'm working with them, and I think: "Geeze, if this were XML-RPC? This would just work. There is zero reason that they need to detail the nuts and bolts so extensively here. Just accept a key-value dictionary, rather than deeply defining these complexities with namespaces, nested types, and on and on."
However, I do not ever think to myself, "Gee, I wish this were REST, and that I was writing out code to encode and decode XML structures."
Yes, it is easier to write a "simple" XML encoder and decoder for basic data, but even simple things take time. Far easier still is to have primitive types go out, and to receive primitive types coming in. Because then I don't need to write an XML encoder or decoder at all.
Again: That's what XML-RPC gets me.
REST is good too -- for what it's for.
I have nothing against REST. I love making a GET and seeing exactly the data structure I asked for. And then I love pulling out the URL for the next chunk of data -- a pointer value within the data structure.
Wonderful!
You can traverse the data structures in so many ways!
But you know what it's not? It's not an automatically functioning API call.
So when I just want to call "server.creditAccount('lion', 300)", it's easier to just use XML-RPC. I don't have to think about POSTs, I don't have to formulate an XML data format; I just ... call it.
A Brief Note on JSON-RPC.
Great! It's... exactly the same as XML-RPC.
Except it's JSON! Everybody loves JSON, right? Primitive types! Awesome!
But how can people be soooo excited when it's JSON, and soooo blase (or worse: "That should be REST!") when it's XML-RPC?
I'm pretty sure that the reason people are excited is because of the "JSON sugar" halo effect.
But really, with both of these RPC mechanisms, you never ever see the underlying transport. Unlike SOAP, they work so great, and so "there's-only-one-way-to-do-it", that the implementations just work.
So who cares at all whether it's XML-RPC or JSON-RPC?
Again: When they work, (and they do both work,) you never ever ever see the underlying transport.
I don't care either way about XML-RPC or JSON-RPC; I just want things to work. If the JSON excitement is enough to get JSON-RPC implemented and defaulted everywhere, fine.
But if your system permits XML-RPC, but not JSON-RPC, and you're wanting JSON-RPC, -- don't hold out. Don't go, "Oh, I won't do this. That is XML-RPC. I heard that XML-RPC isn't RESTful."
A Wish.
The only thing I wish was easier in XML-RPC, and perhaps in JSON-RPC too (haven't had as much experience with it), is: SSL.
Just make the SSL easier to negotiate, and we're golden.
