After watching this talk on REST, Reuse and Serendipity by Steve Vinoski, I wonder if there are business cases in greenfield projects for (XML-)RPC-ish setups, that REST could not solve in a better way.

A few RPC-Problems he mentions:

  • Focus on language (fit the distributed system to the language, not the other way around)
  • "Make it look local" (and cope with failure and latency as exceptions rather than the rule)
  • intended to be language-independent, but still has "function calls" across languages as main ingredient
  • IDL boilerplate
  • Illusion of type safety
  • and a few more ...

Just to dramatize it a bit, some Google Instant results for RPC vs REST:



3 Answers 3


In general, RPC offers far more of a language integration than REST. As you mentioned, this comes with a number of problems in terms of scale, error handling, type safety, etc., especially when a single distributed system involves multiple hosts running code written in multiple languages. However, after having written business systems that use RPC, REST, and even both simultaneously, I've found that there are some good reasons to choose RPC over REST in certain cases.

Here's the cases where I've found RPC to be a better fit:

  • Tight coupling. The (distributed) components of the system are designed to work together, and changing one will likely impact all of the others. It is unlikely that the components will have to be adapted to communicate with other systems in the future.
  • Reliable communication. The components will communicate with each other either entirely on the same host or on a network that is unlikely to experience latency issues, packet loss, etc.. (This still means you need to design your system to handle these cases, however.)
  • Uniform language. All (or mostly all) components will be written in a single language. It is unlikely that additional components written in a different language will be added in the future.

Regarding the point about IDL, in a REST system you also have to write code that converts the data in the REST requests and responses to whatever internal data representation you are using. IDL sources (with good comments) can also serve as documentation of the interface, which has to be written and maintained separately for a REST API.

The above three items often occur when you are looking to build one component of a larger system. In my experience, these components are often ones where their subsystems need to be able to fail independently and not cause the total failure of other subsystems or the entire component. Many systems are written in Erlang to accomplish these goals as well, and in some cases Erlang may be a better choice than writing a system in another language and using RPC just to gain these benefits.

Like most engineering problems, there isn't a single solution to the problem of inter-process communication. You need to look at the system you are designing and make the best choice for your use case.


There are some major advantages of REST when products are scaled up accross a datacenter and you are doing high availability and load balancing.

However, think about a smaller scale project. Needing a webservice that will have a few hundred requests an hour? WCF deals with all the transport issues. Has a convenient interface for sending objects accross the network, and allows the network connection to be configured, encrypted and certified with zero programming using just the application.config file.


You actually can have both. Plugins like RestRPC for Grails provides annotations that will intercept calls to your methods and handle them restfully while allowing you to have as many as you want (which would be very RPC-like).

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.