Skip to content
Soap vs Rest (Why comparing them is a nonsense)

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:

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
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



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.

What Is SOAP

Here is an example of a SOAP request:

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

<?xml version="1.0"?>


<soap:Body xmlns:m="">


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:Body xmlns:m="">


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”?>
<message name="GetStockPriceRequest">
 <part name="StockName" type="xs:string"/>
<message name="GetStockPriceResponse">
 <part name="Price" type="xs:string"/>
<portType name="StockPrices">
 <operation name="GetStockPrice">
 <input message="GetStockPriceRequest"/>
 <output message="GetStockPriceResponse"/>

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 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:

What Is REST

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.



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.



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.

CAP Theorem

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



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.


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

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.


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:

Want to become a super load tester?
Request a Demo