These questions can pop up in any Web project and must be clarified before the initial implementation. Let's start by understanding the concepts of REST and SOAP and draw comparisons about their differences. 

Basic Concepts

 REST

Representational State Transfer is an architectural style for distributed hypermedia systems.

REST is a style of architecture with a set of constraints which allows data transfer over a standardized interface, such as HTTP. REST relies on a simple URI to make a request.

REST is resource based, which means that in a REST service we will work with "things" to define the service. The clients can utilize the REST resource to access a unique URI and the resource is then returned back to the caller. REST uses nouns (i.e. user, country, state, etc.) to define what kind of resource the service should provide. The representation of the resources is not tied to the service itself, which means that the representation of the resource has a free format and can be represented by multiple kinds of data formats (i.e. JSON, XML, CVS, etc.). Below we have an example of REST representation:

Resource: users
Service: contact information (GET)
Representation:
   - name, address, e-mail
   - JSON or XML format
URI: http://rest.org/users

 The REST architecture style has six constraints, which are design rules applied to the architecture and which establish the distinct characteristic of REST services. So, in order to define a REST architecture service, it must have the following architectural characteristics that make any web service a true RESTful API:

1. Uniform Interface: the service must have a defined interface between client and server. It simplifies and decouples the architecture, which enables each part to evolve independently;
2. Client-Server: the separation of concerns between client and server. Clients are not concerned with data storage because it is a server role. Likewise, servers are not concerned about the user interface because it is a client role;
3. Stateless: servers don't store any client context. Each client request must contain all required information to the server in order to understand what is being requested. Session state is therefore kept entirely on the client;
4. Cache: in order to improve scalability and performance, caching should be applied on resources when applicable, thus reducing the client-server interaction. Caching can be implemented on the client or server side;
5. Layered System: REST allows you to use a layered system architecture, which means the service can be deployed in one server and the data storage can be located in a different server. The client cannot tell whether or not it is connected to the end server.
6. Code on Demand: clients are allowed to customize your application in order to return an executable code. A client can call a REST API to get a UI widget rendering code.

SOAP

Simple Object Access Protocol, as the name says, is a standard protocol intended to exchange structured messages in a decentralized, distributed environment.

SOAP is a protocol based on XML to exchange messages across the internet. It has a set of rules which define and describe the messaging format and processing rules for information exchanged between the sender and receiver.  SOAP can use two  different transfer protocols to exchange the messages: HTTP (Hypertext Transfer Protocol) and SMTP (Simple Mail Transport Protocol), but the most popular protocol used by SOAP services is HTTP. Below we have a SOAP Request message as well as an example of the SOAP message structure:

POST /soap/event HTTP/1.1
Content-Length: 309
SOAPAction: ”getEvent”
Content-Type: text/xml;charset=utf-8
Host: ems-sv258:1774
Connection: Keep-Alive

<?xml version="1.0" ?>
<soapenv:Envelope
    xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"
    xmlns:xsd="http://www.w3.org/2001/XMLSchema"
    xmlns:ns1="http://soap.com/act">
    <soapenv:Body>
       <ans:getNote xmlns:ans="http://soap.com/act">
          <eventID>1000</eventID>
       </ans:getNote>
    </soapenv:Body>
</soapenv:Envelope>

Since  SOAP standards for message exchange are based on XML and usually use HTTP as a transport protocol, it is possible to communicate between different applications with different operational systems. 

One specific characteristic of SOAP is the coupling between the service provider (server) and the service consumer (client). There is a rigid contract between the server and client in SOAP and the consumer must know the exact message structure to send to the server. If anything changes on either side, client or server, it will break the communication.

Another important characteristic of SOAP is its association with Web Service Description Language (WSDL). The WSDL has the description of SOAP service and how it works. This makes the client building process easier once IDEs and frameworks can be utilized to automate the implementation based on WSDL.

SOAP also has built-in error handling. When any message has an error or is missing required information, the error response message contains information about what is wrong and can be used by the client to fix the problem. This is very important to consumers when they are not the owner of the service, otherwise, the client won't be able to understand what is wrong with the request.

Comparison

SOAP and REST cannot truly be compared because one is a protocol and the other is an architecture. However, both have the objectives of communication between client and server and data exchange across the internet.

SOAP is the more popular choice for web services when compared to REST due to the restrictive XML messaging format. REST can be used with more lightweight data formats to exchange data. However, SOAP has some key advantages when compared to REST:

1. It is a better option when a formal contract between client and server is required. SOAP enforces the use of contracts provided by the WSDL;
2. SOAP can guarantee some level of reliability and security in asynchronous execution and processing with its built in WS-Reliable messaging specification;
3. SOAP has successful/retry logic built in and provides end-to-end reliability even through SOAP intermediaries. REST doesn’t have a standard messaging system and can only address communication failures by retrying;
4. SOAP has built-in stateful operations. SOAP is designed to support conversational state management while REST is stateless.

On the other hand, there are some advantages of REST when compared to SOAP:

1. REST allows many different data formats like JSON, XML, CVS, MIME types, etc. whereas SOAP only allows XML;
2. REST can be cached and SOAP cannot;
3. REST works better for Limited bandwidth and resources.

Below we are trying to highlight some characteristics of SOAP and REST, given the similarities and differences of the technologies used by each:

There are many factors to be considered when we are talking about REST and SOAP with regards to building web services. For any situation, these variables and requirements must be considered before choosing the best approach to adopt. There is no one best solution, but there is a better approach depending on each scenario. It is up to us, IT professionals, to know how to analyze the scenario and collaborate with stakeholders to develop the best solution.