Enterprise Rails

REST Versus XML-RPC Versus SOAP

We now come to one of the great battles being fought by designers of service-oriented architectures: which protocol is best? The three main contenders in this arena are SOAP, XML-RPC, and REST. Even within the Rails community, the answer has not been consistent. Up to version 2.0, ActionWebService, which makes it easy to make XML-RPC and RPC-based SOAP services, was included with the core of Rails. In version 2.0, it was dropped in favor of ActiveResource, which provides facilities for working with REST services. XML-RPC, SOAP, and REST all provide a means to an SOA end; they all facilitate lopping off a vertical slice of an application and providing remote access over the Internet. And with some allowed deviances from pure REST (or “high REST,” as some call it), any of these three alternatives can be equally well suited to the task of representing any given API.

What differentiates the protocols is the ethos of how a remote protocol should behave and how it should be used. The cultures that have grown around each protocol reflect different views of how systems should be interconnected. In this book, I will take the universalist and also universally contrarian view and suggest that there is no single best protocol and the decision of which to use should be based on the problem at hand. Each design problem is unique: some problems are more easily solved with a REST interface, while others are more easily solved with an RPC-style interface.

Although the ...