25

I am about to build a little server in here and want to create an API for it.

I am deciding what is better and already ruled out SOAP since that thing is a mess in my opinion. I am left with REST and XML-RPC.

I really enjoy XML-RPC, it is really simple to implement and it is regular enough that all clients can use it easily.

These days all the cool kids are doing RESTful stuff, sometimes with a JSON payload or XML document or even HTTP POST variables.

I think those guys always reinvent the wheel for each service. I don't see what one could gain by going with REST over using XML-RPC.

Question:

So, can someone here provide practical reasons for implementing an API using REST+JSON over just using XML-RPC?

Peyman Mohamadpour
  • 17,954
  • 24
  • 89
  • 100
Andre Garzia
  • 983
  • 2
  • 11
  • 19
  • Usually when we talk about "Web" then usually REST style is preferable as it works the HTTP way... Here is a [discussion](http://www.linkedin.com/answers/technology/web-development/TCH_WDD/371332-132625) at linkedin on this subject – Adil Jul 29 '12 at 16:05

2 Answers2

22

REST vs RPC implementations like XML-RPC is a false dichotomy. You can implement a RESTful interface using XML-RPC (although you probably wouldn't want to). That said, there are a bunch of reasons why you would want to expose resources in a RESTful way using vanilla HTTP instead of rolling your own RPC interface using a technology like XML-RPC:

  1. Future actions are primarily controlled by the server instead of hard-coded in the client via procedure calls, simplifying deployment and versioning.
  2. Existing implementations for things like caching, throttling, and versioning can be used out of the box.
  3. The custom procedures that you roll with an RPC interface are likely to be too narrowly scoped.

See this blog post for more info.

Tyson
  • 1,685
  • 15
  • 36
9

  • XML-RPC is patent encumbered. You may find that you're one day asked to pay a royalty for its use. As far as I can tell, REST is not.

  • XML-RPC requests are opaque to security infrastructure. Whereas an HTTP aware firewall could be configured to allow REST calls to read data but not to update or delete it.

The other advantages of REST apply more to dealing with large data-sets.

  • REST is much lighter on the wire (particularly when using JSON rather than XML).

  • XML-RPC ignores HTTP semantics. All XML-RPC calls are HTTP POSTs. This has a number of implications. Including that

    • REST requests benefit from HTTP cacheing infrastructure where all XML-RPC calls must be processed by the target server.
    • REST enables the client to check for updates using a simple HTTP HEAD request. To do the same in XML-RPC, you would need to build it into your API.

  • The XML-RPC client must load the entire response into memory so that can be presented as a return value where it is simple for a REST client to process the stream as it arrives. This means that its quite ok for a REST call to respond with any number of records where an XML-RPC API should limit the size of the response.

Ritchie
  • 1,486
  • 1
  • 15
  • 19
  • 3
    Patents: at a glance there are plenty of patents around aspects of REST as well, so choosing based on royalties seems speculative at best. Security: if you're using HTTP for transport you can read both Header/Body at the Application layer, so I'm not sure what you mean by opaque. Payload: it depends on how the service is built (since calls aren't going to map 1:1) and the format that you're using to expose the data in either case, but you can't guarantee that a RESTful interface will always be "much lighter on the wire". – Tyson Dec 06 '12 at 01:17
  • I agree that patents, security and performance are not good comparison criterias. Regarding performance, there is JSON-RPC, which is lighter than XML-RPC. – Alan Evangelista Dec 05 '14 at 20:55