REST vs SOAP, the difference between soap and rest

Someone asked me a question today “Why would anyone choose SOAP (Simple
Object Access Protocol)
instead of REST (Representational State
Transfer)?”
My response: “The general rule of thumb I’ve always heard is ‘Unless you
have a definitive reason to use SOAP use REST’”. He asked “what’s one
reason?” I thought about it for a minute and honestly answered that I
haven’t ever come across a reason. My background is building great
internet companies.

While he seemed satisfied, I wasn’t very happy with that answer, I did
some homework and here’s my summary on REST versus SOAP, the difference
between SOAP and REST and why anyone would choose SOAP. As usual, with
competing technologies both have value, the challenge is to know when to
use each one (spoiler: luckily the answer is almost always REST).

I’m clearly boiling down a somewhat so please don’t flame me for
simplifying things, but feel free to provide any corrections you feel
are necessary.

Definitions

REST

RESTs sweet spot is when you are exposing a public API over the internet
to handle CRUD operations on data. REST is focused on accessing named
resources through a single consistent interface.

SOAP

SOAP brings it’s own protocol and focuses on exposing pieces of
application logic (not data) as services. SOAP exposes operations. SOAP
is focused on accessing named operations, each implement some business
logic through different interfaces.

Though SOAP is commonly referred to as “web
services” this
is a misnomer. SOAP has very little if anything to do with the Web. REST
provides true “Web services” based on URIs and HTTP.

By way of illustration here are few calls and their appropriate home
with commentary.

getUser(User);

This is a rest operation as you are accessing a resource (data).

switchCategory(User, OldCategory, NewCategory)

This is a SOAP operation as you are performing an operation.

Yes, either could be done in either SOAP or REST. The purpose is to
illustrate the conceptual difference.

Why REST?

Here are a few reasons why REST is almost always the right answer.

Since REST uses standard HTTP it is much simpler in just about ever way.
Creating clients, developing APIs, the documentation is much easier to
understand and there aren’t very many things that REST doesn’t do
easier/better than SOAP.

REST permits many different data formats where as SOAP only permits XML.
While this may seem like it adds complexity to REST because you need to
handle multiple formats, in my experience it has actually been quite
beneficial. JSON usually is a better fit for data and parses much
faster. REST allows better support for browser clients due to it’s
support for JSON.

REST has better performance and scalability. REST reads can be cached,
SOAP based reads cannot be cached.

It’s a bad argument (by authority), but it’s worth mentioning that Yahoo
uses REST for all their services including Flickr and del.ici.ous.
Amazon and Ebay provide both though Amazon’s internal usage is nearly
all REST source. Google used
to provide only SOAP for all their services, but in 2006 they deprecated
in favor of REST source. It’s
interesting how there has been an internal battle between rest vs soap
at amazon. For the most part REST dominates their architecture for web
services.

Why SOAP?

Here are a few reasons you may want to use SOAP.

WS-Security

While SOAP supports SSL (just like REST) it also supports WS-Security
which adds some enterprise security features. Supports identity through
intermediaries, not just point to point (SSL). It also provides a
standard implementation of data integrity and data privacy. Calling it
“Enterprise” isn’t to say it’s more secure, it simply supports some
security tools that typical internet services have no need for, in fact
they are really only needed in a few “enterprise” scenarios.

WS-ReliableMessaging

Rest doesn’t have a standard messaging system and expects clients to
deal with communication failures by retrying. SOAP has successful/retry
logic built in and provides end-to-end reliability even through SOAP
intermediaries.

Summary

In Summary, SOAP is clearly useful, and important. For instance, if I
was writing an iPhone application to interface with my bank I would
definitely need to use SOAP. All three features above are required for
banking transactions. For example, if I was transferring money from one
account to the other, I would need to be certain that it completed.
Retrying it could be catastrophic if it succeed the first time, but the
response failed.

About the Author:

Steve Francia has been responsible for two of the largest commercial open
source projects as the current Chief Operator of the Docker Project and the
former Chief Developer Advocate of MongoDB. Steve has also run some of the top
community-based open source projects: spf13-vim, Hugo, Cobra & Viper

He loves open source and is thrilled to be able to work on it full-time and
then some. In writing, Steve tweets as @spf13,
codes on GitHub,
blogs at spf13.com,
connects on LinkedIn,
ocassionally posts on Google+
and has written a few books for O'Reilly.

In person, he enjoys giving talks and workshops and spending time with the
developer community around the world. When not coding, he is usually having fun
outdoors with his wife and four children.