In the world of web services, two major client-to-server communication systems dominate the field. These systems exist to standardize the mediums and format of communication between clients and servers. Originally developed by Microsoft, the Simple Object Access Protocol (SOAP) was used for almost every web service, but nowadays the Representational State Transfer (REST) is used in 83%¹ or more of API integrations.
REST has grown in popularity as many developers seek to easily create cloud or mobile apps, or automated business applications that leverage SaaS, PaaS, or LaaS apps, although SOAP still dominates in production enterprise-level web services. In order to compare and contrast these systems, it should be explained that SOAP and REST should not be compared directly since SOAP is intended to be a protocol while REST is a software architectural style. In web services, a protocol is a system of rules that define exactly how two communication systems should exchange information whereas architecture is a general blueprint for how a system should communicate with fewer rules. In order to understand the differences between these services, it is necessary to understand each of these services at a deeper level.
SOAP Protocol
Microsoft developed and released SOAP in 1999 to replace antiquated and inefficient messaging systems like the Distributed Component Object Model (DCOM) and Common Object Request Broker Architecture (CORBA). SOAP proved to be superior to these earlier models due to its use of Extensible Markup Language (XML), a human and machine readable standard messaging format. The use of XML allowed disparate systems to communicate with a common language.
SOAP was designed to allow the addition of new capabilities and functionalities. This extensibility is exemplified by the WS-* capabilities of SOAP, such as WS-Addressing, WS-Security, WS-Coordination, along with many other web service standards. WS-Addressing, for example, defined standard ways to route a message over multiple transports or direct a message response to a third party. For example, WS-Addressing can be used to enable a client to requests a response via email or SMS.
SOAP uniquely offers to not use HyperText Transfer Protocol (HTTP) transport. For example, developers can use the Simple Mail Transfer Protocol (SMTP) with SOAP to store and forward messages, providing the option to resend a client request multiple times. This is a more complex topic, though it deserves to be mentioned.
SOAP also requires that both parties have complete knowledge of the APIs in use before any interaction can take place. This enhances security by disallowing any communication that does not abide by the contract between the communicating parties. This abides by ACID (atomicity, consistency, isolation, and durability) compliance and protects databases by dictating all interactions with it, a more conservative model which is favored in financial or private transactions.
Rest Architecture
Roy Fielding created the REST software architecture in 2000 to be a stateless, scalable, reliable communication system that accepts a variety of data formats including HTML, XML, YAML, and JSON. Fielding designed REST to use principles known as the HTTP Object Model combined with the Uniform Resource Identifier (URI). REST services may be referred to as RESTful web services, or REST APIs. All RESTful services abide by several key architectural components, which are detailed below.
REST uses a stateless communication system. This allows for a more lightweight communication between client and servers, as in client-server-server style (CSS). A request to a server must contain all information necessary to understand the request.
REST calls can be cached, as defined explicitly or implicitly in the calls. This allows clients and mediaries to reuse the call later without initiating another request to the server. This functionality enhances speed and efficiency by reducing server lag.
The REST interface is uniform. All implementations of components interface in exactly the same fashion to encourage independent evolvability without jeopardizing the network. This decoupling comes with tradeoffs, as client-server communication cannot be personalized to yield an optimal interface.
Differences between SOAP & REST
Client-Server Coupling SOAP uses strict contracts between clients and servers. REST uses standard methods and general protocols to enable decoupling between client and servers.
Extensibility. SOAP uses pre-built WS-* capabilities to enable more messaging patterns than the typical exchange of requests and responses. REST APIs are currently attempting to be scalable such as GraphQL.
Speed and Bandwidth. REST is generally fast and uses less bandwidth since it can use lighter weight data formats like JSON or plain text, which requires less memory and CPU to parse data. SOAP requires the use of XML.
Security. REST, being transport dependent, uses HTTP with SSL (HTTPS) to secure transmission of messages and validate the client identity. SOAP, being transport independent, use WS-* services like WS-Security to validate that the communication can only be read by the right process on the server. Performance-wise, SSL is faster, but less secure.
Usability. SOAP is still used by Paypal and in private enterprise due to its added security and customizability, though it is more strenuous to set up, update, and use. REST is used by Google (Gmail API), Facebook, Twitter due to its straight-forward interfacing and ease of use.