Comment by jerf | Hacker News Reader

Comment by jerf | Hacker News Reader

Parent Full thread

    Python 2.4.3 (#1,...)
    Type "help", "copyright", "credits" or "license" for more information.
    >>> import xmlrpclib
    >>> server = xmlrpclib.ServerProxy("http://www.something.invalid/xmlrpc")
    >>> server.namespace.function(True, ["A", "B"], {"q": [1, 2, 3]})
    {'A': 8, 'B': ['hello', 8]}

"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.

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.

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.

Reply on news.ycombinator.com