Soap vs Rest (Why comparing them is a nonsense)

I know you won't like this answer... But SOAP vs REST is not the right question to ask. Rest, unlike Soap, is an architectural style, not a protocol. To better understand REST, one should read RESTful Design Principles.

Okay, but Why do some people like SOAP while others love REST? Why is there such a strong emotion around those two names?

Because the best way to compare things is to compare them point by point, we have created a huge table which compares Soap to Rest with 10+ different criterias.

Do YOU have custom Load Testing needs?

Rely on our Expertise

Comparison Table

The following table lists all the key differences between those two protocols:

#	SOAP	REST
On API Changes	Client code must be recompiled with new WSDL	Can be backward compatible
Asynchronous	Yes, Asynchronous Messaging	Synchronous
Bandwidth Usage	+++	+
Cacheable	No	Yes
Data Formats	Only XML	XML, Json, Plain Text, etc
Definition	WSDL Defines the endpoints exposed by the service	Uses XML or JSON to send and receive data
Documentation	The SOAP protocol can be quite difficult to understand (many options), but well documented.	Depends on the documentation provided by the service designer (Swagger for example)
Error Handling	Built-in	No error handling
Exposed Business Logic	Services Interfaces	URIs
Failure Handling	Retry logic built-in	Expects Client to retry
Goal	Focuses on exposing pieces of application logic (not data) as services	Focuses on accessing named resources through a single consistent interface
Invokation	Invokes Services by calling RPC Methods	Simply call services using HTTP Requests
Java API	JAX-WS	Jax-RS
Javascript Support	Difficult	Easy
Network	Transfer over HTTP, SMTP, FTP etc.	Purely HTTP
Official Standard	Yes	No
Statefullness	Supports stateless and stateful operations	Emphasizes stateless communication
Payload	XML Soap Envelop, must comply Soap schema	Can be any format
Payload Constraints	Must support XML Serialization
Performance	Depends on Message Encryption, Signing etc. Typically lower than Rest	Almost no protocol overhead.
Protocol	XML Based Message Protocol	A Free architectural Style Protocol
Reliability	Reliable	Not Reliable, an HTTP Delete can return OK even if it did not work
Security	Supports SSL, but also WS-Security (XML Encryption and Signature)	Depends on the documentation provided by the service designer (Swagger for example)
Time to Market	Slow	Fast
Tooling	Requires significant middleware tooling support	Only HTTP support is required
Who uses it?	Financial, Payment Gateways, Telecommunication	Social Media, Web, Mobile

Examples

SOAP

SOAP is the standard messaging protocol used by Web Services. SOAP's primary goal is inter application communication. SOAP codifies the use of XML as an encoding scheme for request and response parameters using HTTP as a mean of transport.

Here is an example of a SOAP request:

POST /InStock HTTP/1.1
Host: www.example.org
Content-Type: application/soap+xml; charset=utf-8
Content-Length: nnn

<?xml version="1.0"?>

<soap:Envelope
xmlns:soap="http://www.w3.org/2003/05/soap-envelope/"
soap:encodingStyle="http://www.w3.org/2003/05/soap-encoding">

<soap:Body xmlns:m="http://www.example.org/stock">
  <m:GetStockPrice>
    <m:StockName>IBM</m:StockName>
  </m:GetStockPrice>
</soap:Body>

</soap:Envelope>

And the response returned by the server:

HTTP/1.1 200 OK
Content-Type: application/soap+xml; charset=utf-8
Content-Length: nnn

<?xml version="1.0"?>

<soap:Envelope
xmlns:soap="http://www.w3.org/2003/05/soap-envelope/"
soap:encodingStyle="http://www.w3.org/2003/05/soap-encoding">

<soap:Body xmlns:m="http://www.example.org/stock">
  <m:GetStockPriceResponse>
    <m:Price>34.5</m:Price>
  </m:GetStockPriceResponse>
</soap:Body>

</soap:Envelope>

In this example the SOAP request has been sent through HTTP. But it could have been sent through any other network protocol too.

Here is the associated WSDL (document which describes the SOAP endpoints):

<?xml version=”1.0”?>
<definitions>
<message name="GetStockPriceRequest">
 <part name="StockName" type="xs:string"/>
</message>
<message name="GetStockPriceResponse">
 <part name="Price" type="xs:string"/>
</message>
<portType name="StockPrices">
 <operation name="GetStockPrice">
 <input message="GetStockPriceRequest"/>
 <output message="GetStockPriceResponse"/>
 </operation>
</portType>
</definitions>

The WSDL document defines the API endpoints exposed by the SOAP service thoroughly. But, it's a common misunderstanding that WSDL are required for a SOAP service.

WSDL have been added later to the SOAP protocol. This is why the WSDL is optional. They have been added to help understand a web service endpoints. It's quite difficult to know how to call a SOAP web-service without its WSDL definition.

The WSDL has also other benefits:

• Standard way to describe the service endpoints,
• There are tools to generate the code to call the service endpoints in almost any language,
• Most API testing tools supporting SOAP can automatically generate a test suite using a WSDL Definition.

REST

REST is a new and improved form of web services introduced as SOAP is complex. There isn't a standard for REST architectures. REST exposes directory structure-like URIs. It is used to expose a public API over the Internet to handle CRUD operations on data.

REST works on Nouns, Verbs and Content Types:

REST is all about sending HTTP request to specific endpoints and receiving data as a response. Here is an example REST HTTP Request:

GET /articles?include=author HTTP/1.1

Ànd the associated Json response:

HTTP/1.1 200 OK
Content-Type: application/vnd.api+json

{
  "data": [{
    "type": "articles",
    "id": "1",
    "attributes": {
      "title": "JSON API paints my bikeshed!",
      "body": "The shortest article. Ever.",
    },
    "relationships": {
      "author": {
        "data": {"id": "42", "type": "people"}
      }
    }
  }],
  "included": [
    {
      "type": "people",
      "id": "42",
      "attributes": {
        "name": "John",
        "age": 80,
        "gender": "male"
      }
    }
  ]
}

REST stands for Representational State Transfer.

It mostly relies on a software architecture based on the stateless network protocol, known as HTTP (Hyper Text Transfer Protocol). REST can rely on many different data structures like JSON, XML, YML and more. Most Rest APIs are based on human-readable protocols (although there are binary protocols too, like the one Oracle Forms uses).

Json is the most widely used payload data structure as of now. While SOAP is strongly function oriented, REST is mostly data driven. It means Rest is mostly designed to get / put data, while SOAP is mostly designed as an RPC (Remote Procedure Call).

State of the Debate

There used to be a lot of debate around SOAP versus REST—“there’s no right answer” or “it’s all about priorities, personal preference.” It’s been about 15 years since REST was initially proposed by Roy Thomas Fielding (wiki) and a lot of the articles that say REST is the “new kid on the block” and “ever-gaining in popularity” are ten-plus years old.

The debate around SOAP and REST has been soaring for several years. Is it really worth it? From our point of view, both have strengths and weaknesses. It really depends on your project needs.

While REST has taken the fold over SOAP in the last 10 years, SOAP is still used for mission critical APIs. In fact, SOAP is best suited for long-hawl projects with strong emphasis on security and reliability. On the other side, Rest is best suited for projects with strong emphasis on simplicity and performance.

Rest Benefits

Here are all the benefits we see using Rest:

• Standard HTTP communication which traverses most firewalls with ease,
• REST is easier to scale: reads can be cached,
• Large Developers community, and many public facing apis using it,
• Lightweight because there is no protocol overhead,
• It works with both XML and Json, or whatever format you would like to use (including esoteric binary encrypted protocols),
• Javascript Friendly: executing HTTP requests is natively supported, especially with Json payloads,
• Faster Time to Market: Rest has free standards, letting you implement the logic between your client and server as you wish.

REST is generally preferred by small to medium organisation who have lower requirements on security. Simplicity is also often an argument in favor of REST when dealing with public APIs.

SOAP Benefits

Here are all the benefits we see using SOAP:

• Strong emphasis on standards: SOAP has an official standard which you must comply to,
• Best suited for large Enterprise projects, simply because it has a number of features like XML encryption, automatic retry on failure etc,
• Security is first class citizen, with built-in security features to protect messages from being corrupted,
• W3C standard,
• Comments and Embedded documentation supported,
• Service definition via a standard WSDL document,
• Best suited for stateful communications,
• Supports many transport protocols including HTTP, SMTP, plain sockets and more,
• SOAP’s standard HTTP protocol makes it easier for it to operate across firewalls and proxies. But, because it uses the complex XML format, it tends to be slower compared to middleware such as ICE and CORBA,
• And ACID-compliant Transactions.

SOAP is still used in many big organisations. With built-in security and reliability functions, SOAP is a great choice for applications where security is more critical than performance. SOAP is highly extensible. In addition to WS-Security, SOAP supports WS-Addressing, WS-Coordination, WS-ReliableMessaging, and a host of other web services standards, a full list of which you can find on W3C.

WS-Security

While SOAP supports SSL (just like REST) it also supports WS-Security. 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.

This protocol is about achieving end-to-end security by using encryption and cryptographic signing. Messages may pass through intermediaries of lower trust without risks. To be honest, an encrypted transport channel would do much better all the way from one endpoint to the other: This is called SSL (Secure Socket Layer).

If you ever need it, you can implement an encryption / signature protocol using your favorite technologies for this. But this would make your services less interoperable.

Some people will argue SSL is prone to hacking, just remember no technology is safe. Some are just safer than others.

WS-AtomicTransaction

Need ACID Transactions over a service? you’re going to need SOAP.

In computer science, ACID (Atomicity, Consistency, Isolation, Durability) is a set of properties of database transactions intended to guarantee validity even in the event of errors, failures etc.

While REST supports transactions, it isn’t as comprehensive and isn’t ACID compliant. The good news is ACID transactions rarely make sense.

REST is limited by HTTP itself which can’t provide two-phase commit across distributed transactional resources. SOAP can via WS-AtomicTransaction. While internet apps usually don't need this, enterprise-grade apps may.

But, Distributed transactions are an antipattern. Some say they should never be used. It's even becoming a serious headhache in microservices.

Distributed transactions destroy your scalability, and they force you to give up either availability or network fault tolerance. The CAP Theorem also named Brewer's theorem after computer scientist Eric Brewer states:

It is impossible for a distributed data store to simultaneously provide more than two out of the following three guarantees:

• Consistency: Every read receives the most recent write or an error,
• Availability: Every request receives a (non-error) response – without guarantee that it contains the most recent write,
• Partition Tolerance: The system continues to operate despite an arbitrary number of messages being dropped (or delayed) by the network between nodes.

Use compensating transactions instead. If consistency is needed, define a single source of truth and do ACID transactions within it.

WS-ReliableMessaging

WS-ReliableMessaging describes a protocol that allows SOAP messages to be reliably delivered between distributed applications in the presence of software component, system, or network failures.

Rest doesn't have any retry protocol. (although you can implement your own on top of it) SOAP has successful/retry logic built in and provides end-to-end reliability even through SOAP intermediaries.

But, WS-ReliableMessaging guarantees only reliable transport, not reliable application processing. It makes it unsuitable for reliable messaging. Nobody Needs Reliable Messaging explains this in great details.

The RESTful way to do reliable messaging is to use idempotency. The solution is to make sure repeated calls to a single service doesn't affect the result more than once.

Use-Cases

Let's take some real-world use-cases and see which protocol is best suited for each:

User-Case	SOAP	REST
Public Facing API		X	Simplicity is one of the strongest reasons to opt for REST.
High Throughput API		X	Rest is preferred for performance reason (lot of requests)
Payment System	X		Soap is preferred for security reasons
Mobile Application		X	REST with Json is the standard as of now

It's not a coincidence that most new APIs are built around Rest and Json. Frontends are mostly written in Javascript now: this language has native support for Json parsing and HTTP requests.

Useful Resources

Here are some services which can help you to try out both SOAP and REST services:

• HTTPBin: very simple Rest APIs with most common use-cases.

Conclusion

Saying that REST or SOAP is better than the other is fundamentally wrong. Both have specific usages, strengths and weaknesses. Out of the context of a given project, it's impossible to tell whenever SOAP or REST is better. It all depends on your needs.

However, the emergence of REST with Json over HTTP versus SOAP over HTTP shows there is a stronger need for simplicity and performance than reliability and security.

SOAP vs REST is a highly emotional debate. You will find both detractors on the internet.

Here are some useful resources to dig further this subject:

• Why Rest Is Better Than SOAP (in some cases),
• SOAP and REST Comparison,
• Why SOAP Sucks,
• Google Abandons SOAP,
• and more.

Want to become a super load tester?

Request a Demo