While SOAP and REST share similarities over the HTTP protocol, SOAP is
a more rigid set of messaging patterns than REST. The rules in SOAP are
important because we can’t achieve any level of standardization
without them. REST as an architecture style does not require processing
and is naturally more flexible. Both SOAP and REST rely on well-
established rules that everyone has agreed to abide by in the interest
of exchanging information.
A Quick Overview of SOAP
SOAP relies exclusively on XML to provide messaging services.
Microsoft originally developed SOAP to take the place of older
technologies that don’t work well on the internet such as the
Distributed Component Object Model (DCOM) and Common Object
Request Broker Architecture (CORBA). These technologies fail because
they rely on binary messaging. The XML messaging that SOAP employs
works better over the internet.
After an initial release, Microsoft submitted SOAP to the Internet
Engineering Task Force (IETF) where it was standardized. SOAP is
designed to support expansion, so it has all sorts of other acronyms
and abbreviations associated with it, such as WS-Addressing, WS-Policy,
WS-Security, WS-Federation, WS-ReliableMessaging, WS-Coordination,
WS-AtomicTransaction, and WS-RemotePortlets. In fact, you can find a
whole laundry list of these standards on Web Services Standards.
The point is that SOAP is highly extensible, but you only use the pieces
you need for a particular task. For example, when using a public web
service that’s freely available to everyone, you really don’t have much
need for WS-Security.
Difficulty Depends on Programming Language
The XML used to make requests and receive responses in SOAP can
become extremely complex. In some programming languages, you
need to build those requests manually, which becomes problematic
because SOAP is intolerant of errors. However, other languages can use
shortcuts that SOAP provides. They can help you reduce the effort
required to create the request and to parse the response. In fact, when
working with .NET languages, you never even see the XML.
Part of the magic is the Web Services Description Language (WSDL).
This is another file that’s associated with SOAP. It provides a definition
of how the web service works, so that when you create a reference to it,
the IDE can completely automate the process. So, the difficulty of using
SOAP depends to a large degree on the language you use.
Built-In Error Handling
One of the most important SOAP features is built-in error handling. If
there’s a problem with your request, the response contains error
information that you can use to fix the problem. Given that you might
not own the Web service, this particular feature is extremely important;
otherwise you would be left guessing as to why things didn’t work. The
error reporting even provides standardized codes so that it’s possible
to automate some error handling tasks in your code.
An interesting SOAP feature is that you don’t necessarily have to use it
with the HTTP transport. There’s an actual specification for using SOAP
over Simple Mail Transfer Protocol (SMTP) and there isn’t any reason
you can’t use it over other transports. In fact, developers in some
languages, such as Python and PHP, are doing just that.
A Quick Overview of REST
REST provides a lighter-weight alternative. Many developers found
SOAP cumbersome and hard to use. For example, working with SOAP in
JavaScript means writing a ton of code to perform simple tasks because
you must create the required XML structure every time.
Instead of using XML to make a request, REST (usually) relies on a
simple URL. In some situations you must provide additional
information, but most web services using REST rely exclusively on using
the URL approach. REST can use four different HTTP 1.1 verbs (GET,
POST, PUT, and DELETE) to perform tasks.
Unlike SOAP, REST doesn’t have to use XML to provide the response.
You can find REST-based web services that output the data in
Command Separated Value (CSV), JavaScript Object Notation (JSON) and
Really Simple Syndication (RSS). The point is you can obtain the output
you need, in a form that’s easy to parse within the language you’re
using for your application.
Deciding Between SOAP and REST
Unless you plan to create your own web service, the decision of which
protocol to use may already be made for you. Extremely few web
services, such as Amazon, support both. The focus of your decision
often centers on which web service best meets your needs, rather than
which protocol to use.
Soap Advantages
SOAP provides the following advantages when compared to REST:
• Language, platform, and transport independent (REST requires use
of HTTP)
• Works well in distributed enterprise environments (REST assumes
direct point-to-point communication)
• Standardized
• Provides significant pre-build extensibility in the form of the WS*
standards
• Built-in error handling
• Automation when used with certain language products
REST Advantages
REST is easier to use for the most part and is more flexible. It has the
following advantages over SOAP:
• No expensive tools require to interact with the web service
• Smaller learning curve
• Efficient (SOAP uses XML for all messages, REST can use smaller
message formats)
• Fast (no extensive processing required)
• Closer to other web technologies in design philosophy
