<p><pre><code>    Python 2.4.3 (#1,...)
    Type "help", "copyright", "credits" or "license" for more information.
    &#62;&#62;&#62; import xmlrpclib
    &#62;&#62;&#62; server = xmlrpclib.ServerProxy("http://www.something.invalid/xmlrpc")
    &#62;&#62;&#62; server.namespace.function(True, ["A", "B"], {"q": [1, 2, 3]})
    {'A': 8, 'B': ['hello', 8]}
</code></pre>
"REST" can't match that. "REST + some other stuff I layer on top" can, but you have to bring more to the party; for instance, you can decide that everything will be JSON coming back, but you had to decide that, so you had to do the work. On the other hand as is so often the case with this increased responsibility you get more power; XML-RPC has no decent binary capabilities, for instance, which is easy with REST.<p>That doesn't mean the work isn't worthwhile. My personal feeling is that if XML-RPC meets your needs, you should probably use it, but if it doesn't, don't hesitate to move on. RPC is a crazy and cruel world, though; here there be dragons. REST is better than starting from scratch in most ways but you can still end up down the rabbit hole surprisingly quickly. For instance, REST tempts you into considering caching in a layer designed for caching human document accesses; this may or may not actually have the semantics you are interested in and it can get subtle.