I really hate this darn machine;
I wish that they would sell it.
It won't do what I want it to,
but only what I tell it.
~Author Unknown
My intent for this post is to be a 5 minute primer on the major differences between REST and SOAP. Of course, some folk may find a short post inadequate to discuss this particular topic, but hopefully many of you will find this helpful in some way. Before we get started, I'd like to point out that there are many alternatives to these two technologies that won't get discussed here, including (but not limited to) Binary XML, DCOM, CORBA, ICE, .Net Remoting, etc, each of which have their own unique advantages and disadvantages. REST and SOAP, however, are likely the more well-known and more accessible (i.e. easy to pick up).
A look at SOAP
The acronym SOAP was originally defined as Simple Object Access Protocol, but as of version 1.2 of the standard that meaning was dropped in favor of the (allegedly) more accurate Service Oriented Architecture Protocol. SOAP is an XML based protocol which provides for the passing of messages over a network, from computer to computer. In my humble opinion, the original acronym provides a more accurate description of its use today as an IT Enterprise solution for object transfer. But for the purest out there, allow me to clarify that SOAP does not pass objects over the wire, but messages.
Here's a sample SOAP request ("borrowed" from w3schools.com), which requests the current stock price for ticker symbol IBM:
<?xml version="1.0"?>
<soap:Envelope
xmlns:soap="http://www.w3.org/2001/12/soap-envelope"
soap:encodingStyle="http://www.w3.org/2001/12/soap-encoding">
<soap:Bodyxmlns:m="http://www.example.org/stock">
<m:GetStockPrice>
<m:StockName>IBM</m:StockName>
</m:GetStockPrice>
</soap:Body>
</soap:Envelope>
And the response would look something like this:
<?xml version="1.0"?>
<soap:Envelope
xmlns:soap="http://www.w3.org/2001/12/soap-envelope"
soap:encodingStyle="http://www.w3.org/2001/12/soap-encoding">
<soap:Bodyxmlns:m="http://www.example.org/stock">
<m:GetStockPriceResponse>
<m:Price>34.5</m:Price>
</m:GetStockPriceResponse>
</soap:Body>
</soap:Envelope>
SOAP is obviously very verbose. But it's approach is also very object-oriented, which makes it easy for most object-oriented developers to wrap their brains around. A SOAP service could be considered an object, which contains several methods that can be invoked, or properties that describe the object. If we used .Net to create a proxy class to call this web service, the C# code to invoke the GetStockPrice method might be something like this...
StockService service = new StockService();float currentStockPrice = service.GetStockPriceResponse();Console.WriteLine("Current stock price: {0}", currentStockPrice);I'm using .Net here mainly to illustrate my point, which is that calling a web service looks and feels very object oriented. Even though we're not actually passing objects over the wire, it feels like we are, and so it's easy to work with.
A look at Representational State Transfer (REST)
In its most basic form, a RESTful service is "just" a URL that provides access to a resource. For example, a RESTful URL to get Apple's latest stock price might look something like this:
http://URI/CurrentStockPrice/AAPL/
Or maybe like this:
http://URI/CurrentStockPrice?AAPL
The World Wide Web is the most oft-cited example of RESTful design. Web pages support POST, GET, PUT, and DELETE, often used by RESTful applications to retrieve or modify data. Some RESTful applications add their own HTTP methods, such as WebDav, which adds PROFIND, PROPPATCH, MKCOL, COPY, MOVE, LOCK, and UNLOCK.
REST is very intuitive for GET operations, and is a popular architectural choice for services on the public Internet. For example, Amazon and Google both provide RESTful interfaces to their APIs, and according to Jeff Barr, Amazon's chief web services evangelist, 85% of developers prefer Amazon's REST interfaces over their SOAP counterparts (Amazon provides both).
SOAP seems to be more easily adopted by the Enterprise, while REST is a natural fit for publicly facing Internet applications, in particular those applications where most operations are retrieving data (versus writing/posting/updating data). For example, XML results from a RESTful service seem more conducive to formatting with XSLT, simply because of the absence of the "extra" SOAP XML.
An RSS feed is a great example of a RESTful interface. I just point my favorite news reader to an RSS URI, and it's easily consumed. I can save the feed results to an XML file and easily convert it to XML using an XSL style sheet. REST is a data consumer friendly interface.
Which is Best?
Is one better than the other? I would say: hardly. That would be rather like choosing VB.Net over C#. Many developers may prefer one over the other, but you can get the job done using either tool.
On the flip side, I might recommend considering the desired feel of your application's API when choosing betwixt these two technology choices. Consider SOAP's object-orientedness vs. REST's web request based feel, and how each might impact adoption of your API.
Or, if you're using a technology like Microsoft's Windows Communication Foundation, which provides built-in support for both SOAP and REST, you won't have to choose at all.
But at least you'll know the difference.
