3 ms·

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: "12

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.

ramen 17y ago
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.
jodrellblank 17y ago
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.
- jerf 17y ago
  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/035207.html 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.

ramen 17y ago

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.

jodrellblank 17y ago

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.

jerf 17y ago
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/035207.html 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.