If XML-RPC is really better than REST, it’s not for there reasons.
Dave Benjamin summarized on his blog 10 reasons why XML-RPC should be better than REST but I think he completely missed the point about REST APIs. Let’s see:
1 - Standard, cross-language, typeful serialization of data
REST is definitely standard and cross-language. Regarding serialization, you can transfer what you want where you want but if your goal is persisting to make a local resemblance of what you have remotely, I think that’s bad. What we, as developers, really care is having the possibility to use a service remotely with an eye on scalability and transparence. Hence, HTTP 
2 - User-defined error codes and messages
Nobody forbids anyone to invent your own headers and place whatever meaning you want upon them. With HTTP you can surely do that. Even whole extensions have been written.
3 - “Boxcarring” of requests to reduce overhead
Box carring is not really an advantage, there are other ways to reduce overhead. See also 207 multi status
4 - Serialization of binary content
Who said REST protocols do not support binary data? You can send whatever you want from the client to server, place the right content type and you’re done. See also media resources in the Atom Publishing Protocol.
5 - Serialization of date-time values
Do I really have to answer that?
6 - Standardized parameter passing
And what if I want to pass a parameter that’s not on the list of the allowed types in the specification? Remember, SOAP has born also to address some of the limitations of XML-RPC.
7 - Introspection allowing for straightforward code generation
Let me say one thing once and for all. Code generation for this purposes is bad, and almost useless (if you are used to highly dynamic languages). Anyway, REST through hypertext is implicitly introspection enabled. Also, documentation of APIs is there for us
8 - High-level APIs for just about every language
I think there’s no need to say that each and every language has some sort of HTTP client.
9 - No manual parsing of XML, ever
This point does not really make sense to me. If one XML-RPC method does return XML as content, you have to parse it because is part of the application domain. The same for SOAP or REST. If, as Dave mentioned, the language has some sort of high-level API for the protocol you don’t have to parse what’s on the wire manually: no manual parsing of XML-RPC responses, or SOAP envelopes or HTTP responses.
10 - Only three lines to call a function in Python and several other languages
This is really pointless. Using a REST API from httplib2 or restclient has the same brevity.
I think Dave did not get REST at all, his conclusion speaks for him:
Not that the REST doesn’t have its benefits, but someone ought to be saying this. XML-RPC isn’t complicated like SOAP, it runs just about everywhere, and it lets you get on with your work rather than arguing about semicolons versus slashes or XML versus JSON or countless other things. Besides, when your goal is to support as many languages as possible, you want to minimize the amount of code you write for each language. As far as I’ve seen, nothing else accomplishes literally no-code binding like XML-RPC.
I suggest reading RESTful Web Services, it’s really a good book. I also suggest reading the last article wrote by Stefan Tilkov addressing the most popular REST doubts.
