XML-RPC vs REST in a new implementation - which would you pick?
If you had the chance to build an enterprise API from scratch, would you base it on REST or XML-RPC? Why? Would you pick something else entirely? If so, what?
Answers (12)
Luís L
Customer Operations CSRM at Cisco
Best Answers in: Organizational Development (2), Customer Relationship Management (1), Change Management (1), Philanthropy (1), Blogging (1), Using LinkedIn (1)
I would call upon the below experts for the answer.
Cheers
Luís L also suggests these experts on this topic:
Ken is your client abrowser? REST is your better choice if this is the case.
If a client is independent, (desktop service, mobile apps etc) then XML-RPC is the better choice.
Take a look at this blog
http://www.michaeldehaan.net/?p=665
JRGS
It's going to depend on the specifics of the situation. That said, though, I think that REST passing of JSON-encoded data is probably the best starting hypothesis, these days. There's nothing magical about JSON or REST, of course, and the technical world has hardly decided this issue. I think it is pretty clearly headed in this direction, though, at least for now.
JSON hits a relatively decent sweet-spot of being able to represent most arbitrary data structures, in a fairly reasonable, straight-forward and light-weight fashion. Anyone who has worked with any modern scripting language is going to immediately recognize the That, combined with the general level of acceptance and support make it a pretty natural choice for many situations.
Similarly, REST is not a magic bullet, but a pretty sensible and light-weight option. You forego the need to really invent a new protocol or add another heavy protocol layer, by simply using HTTP, more or less as it is.
Just how strongly to follow all the dogma of REST is another matter, of course, and depends on what you are trying to accomplish. Hard line REST puts a strong emphasis on "nouns over verbs." That is, a focus more on passing data objects, possibly representing state changes, rather than passing actions, which might affect the state of said objects. I find this approach makes more sense the more loosely coupled the systems on either side of your API are. I find that for more tightly coupled systems, though, "verbs" can be a much lighter-weight and simpler way of expressing remote calls. It's highly situation dependent.
In other words, you can choose to only offer PUT, GET, and DELETE on big objects via your API, or you can compromise with more classical remote-procedure-call encoded in POST requests (and maybe GETs for read-only, cacheable operations). I prefer the practicality of a given problem's needs to dogma.
REST is an HTTP based protocol. Whereas XML-RPC is XML based. REST being an HTTP based protocol works best when the client is a browser. XML-RPC on the other hand is XML based. So no assumption is made about the client which is going to use the protocol be it a desktop application a mobile application, a mashup using information from your site can easily integrate with XML-RPC. When the client is a browser, more efforts need to be put in by the client to use XML-RPC than to use REST. An advantage of REST over XML-RPC is that each object has its own URL and can easily be cached, copied, and bookmarked. REST has its advantages in the browser world. But as more and more applications are using the web as a platform and accessing it through a variety of methods other than web browsers XML-RPC has and edge over REST.
You can also visit the following links to have more clarity
Links:
http://ramenlabs.com/2008/02/17/ten-things-that-xml-rpc-does-that-rest-leaves-unspecified/
http://www.oluyede.org/blog/2008/03/24/if-xml-rpc-is-really-better-than-rest-its-not-for-there-reasons/
Simon B
General Partner at Ash Biotech. CEO at Psynixis
Best Answers in: Biotech (2), Enterprise Software (1)
I would (and have) picked REST over XML-RPC and other technologies, for the following primary reason: it's super easy, and super quick, for the developers that will use the API to get up and running with a REST API, using the programming language of their choice.
If this is a service to be browsed by a web browser, then REST.
You get SEO baked in for free.
Stuart.
I vote for REST over XML-RPC as well.
Johnny L
Kernel/Networking Trainer & Consultant
Best Answers in: Information Security (4), Computer Networking (3), Computers and Software (2)
Hi Ken,
I side with the XML-RPCers. This is in favor of the client agnostic nature of it. Using REST ties you to using a browser, whereas XML-RPC can *also* be handled by a browser.
Now, for all those who comment about JSON - JSON is no panacea - it opens up some serious security concerns, chiefly cross site scripting issues. Its only advantage is its easy serialization and deserialization of objects - but the same can be accomplished with a Javascript wrapper function that handles to/from XML - and said wrapper is no more than 30 lines of code (Do let me know if you need something like that).
XML-RPC also has various other advantages, especially when incorporated with XSL (XML Stylesheets) for the presentation layer. This allows you to truly decouple the data from the presentation thereof, and provides for scalability and forward compatibility.
Gaurav S
Founder & CEO at Think Mantra, Inc. - An SEO Company
Best Answers in: Starting Up (2), E-Commerce (1), Computers and Software (1)
If the primary use is for the web, I'd go with REST. As Simon also pointed out, it is really easy to develop and test.
If your reason to consider XML-RPC is supposed ability to define strongly typed relatively complex contract( API) and then generate clients, then I would say .... 'fo'get 'baut it'
In reality there are so many little nitty-gritty details and incompatibilities, and inconveniences, that it really gets simple to generate request and parse response 'manualy'.
Practically I see so many interfaces end up defining API in WSDL where request and response are defined as 'string' and then those 'strings' are actually XML documents which still need to be generated and parsed by hands.
So I suggest doing XML over HTTP, or JSON as Steven suggested.
If you really want a working RPC then I suggest looking at Hessian, AMF3, or HTTPRemoting(for Java)
Links:
Our team battled with this question for years @ Verio. We were choosing between XML-RPC, SOAP, and REST. We went the XML-RPC route and I actually think we would have been better with a REST implementation because there are some development language that do not have good XML-RPC libraries. As an API user, I have found over the years that the best and most simple APIs are based on very simple rest implementation. It is what Amazon and Google uses. Either way you go, another important thing I would recommend is to keep each API method simple. We also made the mistake of creating some methods that did too much and took too many args. Good Luck.
REST.
Because that is just the most natural implementation, in fact web itself is actually a REST implementation.
