REST versus SOAP. It’s been an issue for a while now. And really, they’re just two answers to the same question: how to access web services.
But deciding one over the other can be surprisingly difficult.
SOAP (Simple Object Access Protocol) is a standards-based web services access protocol that has been around for a long time. Originally developed by Microsoft, SOAP isn’t as simple as the acronym would suggest.
REST (Representational State Transfer) is another standard, made in response to SOAP’s shortcomings. It seeks to fix the problems with SOAP and provide a simpler method of accessing web services.
What about GraphQL?
Of course, GraphQL has recently made a huge splash, which we’ve spoken
of at length in other articles. But it’s still not as standardized as
REST and SOAP, so in this article we’re just going to focus on those
two.
Both SOAP and REST have issues to consider when deciding which protocol to use.
The Similarities
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.
Request Form