Why are most web services in REST style, and not (also) in XML-RPC?

views:

371

answers:

+4 Q:

Why are most web services in REST style, and not (also) in XML-RPC?

I know that Flickr provides both XML-RPC and REST ways of working with it.

There are standard XML-RPC libraries for every language (For example, Python has a built-in one xmlrpclib).

Standard XML-RPC libraries takes care of the serializing/deserializing as well as sending/receiving the responses.

It seems to me that websites that use the REST style for the same API would end up writing their own libraries in each language. Example: the Yahoo! Search SDK.

To me, it seems that the XML-RPC way is better, but all the evidence is to the contrary. Why?

So:

Why are most web services in REST style, and not in XML-RPC?
Are there downsides to XML-RPC that is not apparent?

Simple Answer: REST tends to be easier to implement

Zoomzoom83 2009-04-02 07:53:26

For the client or the server? If it is the server, I think that is also pretty standardized - http://docs.python.org/library/simplexmlrpcserver.html , isn't it?

Swaroop C H 2009-04-02 08:17:02

Is it really? Amazon's so called REST services aren't RESTful, even though the co-author of *the* book on RESTful webservices works at Amazon. Flickr's so called "REST" webservice isn't RESTful. Ruby on Rails' so called "REST" interfaces aren't RESTful. It doesn't look very easy to me.

Jörg W Mittag 2009-04-02 11:47:34

Roy Fielding recently had a blog article, in which he explained that just because REST is a simple design, it is not simple to design. In fact, that is one of the basic laws of design: the simpler the design, the more work it is.

Jörg W Mittag 2009-04-02 11:49:31

+3 A:

Rest is not just easier, its a lot easier.
Xml-Rpc/soap has a lot of moving parts and a hefty amount of overhead, cognitive
and otherwise which (very often) is not needed, its complex and unless you specifically need some of the features it provides it's just not worth it
Not every service request needs to be packaged up as a formal function call with parameters
REST is also a formal system that's well defined and a great model for representing the resources available on the web (hence the term REST)

Having said that, it's easy to make a lot of newbie mistakes using REST so google around for how to use it first, you'll be happy you did.

jottos 2009-04-02 08:26:39

I disagree with REST being easy. I've hardly seen anyone use REST correctly.

Wahnfrieden 2009-07-22 14:55:10

there are many discussions on that on the web, so I won't go deep on the answer. In short: It's easy. Easy to write, easy to understand, easy to debug. You can write it on your browser and it will probably bring back something useful. Very good.

This easiness come at the price of less "possibilities" but the theory goes that in the long run, easiness might be more worthy.

Liorsion 2009-04-02 08:48:18

"You can write [the URL] on your browser and it will probably bring back something useful." +1

Lucas 2009-04-02 13:02:11

This is nonsense, sorry. What does that even mean? The only thing typing a URI in you browser supports is the GET method anyway. And this has absolutely nothing to do with REST.

Wahnfrieden 2009-07-22 14:54:00

check out REST on wikipedia (http://en.wikipedia.org/wiki/Representational_State_Transfer) - rest is using HTTP (although doesn't have to do with web) - which is GET, as you said.REST is very simple - it's the idea of using resources vs. request parameters, that's it. Obviously it has some agenda behind it, but this is the main point.So instead of having request.com/user=lior you would have request.com/user/lior - to work on my user, and the GET will get the information, POST would set a new user, [http] DELETE would delete it etc. Sorry if it sounds nonsense to you, but that's REST.

Liorsion 2009-07-23 06:43:52

The Wikipedia article is in dismal condition, and even Fielding himself (the creator of the REST specification) disagrees with it. It does not rely on authoritative sources. What it says about REST being about HTTP is incorrect.

Wahnfrieden 2009-07-23 14:28:44

+1 A:

This is a great question. Unless you are taking advantage of hypermedia for discovery and standard media formats then you are not likely to be getting the benefits of REST. You might as well stick with XML-RPC.

Darrel Miller 2009-04-02 12:17:31

REST is the native architectural style of the Web. (In fact, it was reverse-engineered from the way the Web already works.) XML-RPC and SOAP attempt to take a very different (procedural, imperative) programming model and adapt it to the web. The result is that REST ends up being cleaner and more flexible.

Jens Alfke 2009-04-29 23:56:19

This is totally incorrect. REST is protocol-independent and isn't specifically about the web. The "native architectural style of the web" is just HTTP and using HTTP correctly does not mean that you are being RESTful.

Wahnfrieden 2009-07-21 15:41:06

ansaurus

tags:

views:

answers:

Why are most web services in REST style, and not (also) in XML-RPC?

related questions