Caching has been the main reason I have chosen REST over XML-RPC in certain instances - the ability to use existing web proxy and caching solutions to cache an API is certainly convenient. However, I completely agree about your last sentence here. Cache invalidation is tricky, since there isn't a standard HTTP method to tell a web cache to forget something it has cached. Also, client-side caching at a higher level using something like memcached has worked demonstrably better for me in many instances, and it offers more fine-tuned control over lifetime and expiration.

I'm confused about your Python example and how REST can't achieve that.

  bash$ curl http://my-fake-service.com/people/1.json
  {name: "John Doe", address: "123 Fake St"}

I think opposite you, however. My feeling is that REST will probably meet your needs, and if for some reason you're required to use XML-RPC, then use that. It all depends on your starting point and biases.

The difference is that your example uses a URL as input and outputs a JSON blob. The URLs still need to be constructed somehow and the output needs to be parsed if you want to do anything useful with this service. To compare apples-to-apples:

    >>> import urllib, simplejson
    >>> person_id = 1
    >>> person = simplejson.loads(urllib.urlopen('http://my-fake-service.com/people/%d.json' % person_id).read())

Now you have a data structure you can work with. But you've just traded a nice parameter-passing syntax for string building, and you're parsing JSON manually. Of course, you could wrap all of this with an API, and you probably should, but XML-RPC does a lot of this wrapping for you.

Not so much "can't" achieve it, but doesn't.

With xmlrpclib, serving functions over XML-RPC is a library import, a server class instantiation and a one line instruction to serve a function, and on the client side an import, a connection and a function call.

After that they behave much as any other functions (+latency), parameters are encoded and return values decoded all behind the scenes, neither the server function nor the client need have any special 'written-for-XML-RPC' changes for it to work.

It's more a case of a well implemented Python module than an inherent win over REST - there could be a similar module for REST-RPC created, but AFAIK there isn't one at the moment.

REST-RPC is obviously possible, but would be additional stuff on top of REST, and... I guarantee you that REST advocates would flip out. By and large they think that having things that don't cleanly map down to RPC is a benefit; they would object that a function call lacks the richness to fully represent the results of a REST invocation: Did you get a cached value back? Can you get to the HTTP headers? Can you set cache header on the request itself, or other HTTP headers? And there's a lot of truth here. Basically, REST-RPC would be "an RPC mechanism built on top of REST", but would not be "REST that is also RPC"; REST-RPC must necessarily be at least one of "a significantly limited subset of REST" or "more complicated than a simple function call".

Despite the fact I'm not willing to write off XML-RPC as absolutely useless as I believe there are times for simplicity, I also tend to agree that for industrial strength purposes RPC is a bad metaphor and you basically lose if you try to use RPC. It's just that I don't think REST is the right direction; I head more in the direction of message passing, as laid out in

http://www.erlang.org/pipermail/erlang-questions/2008-May/03...

And REST would agree with at least some of that; at least REST isn't hiding the fact that your function call is not local from you. But it falls afoul of many of the criticisms, too.