The clearest analogy is in this Postman article, which compares SOAP to a National Postal Service: "(SOAP) is older, established, and dependable" but it can be slower than competing architectural styles like REST."
We will first look closely at SOAP and REST APIs, then move on to their differences and similarities.
The SOAP API is in some ways the predecessor to the REST API, but it is distinct from REST. SOAP is a protocol, while REST is a style.
SOAP API requests and responses are formatted with XML, and while extensible, are strictly formatted and more bandwidth intensive than JSON (Java Script Object Notation). Like REST, they are transmitted with HTTP messaging, but can also use SMTP, TCP, and UDP, which can be a big benefit in the right use cases.
While XML allows for data to be described any way you like, the SOAP schema requires a specific structure around that data.
SOAP web services are still widely used, especially in enterprise and banking applications, where the strict contracts of XML schema maintain stability and structure in responses and requests. It requires more bandwidth to transmit verbose XML states with every request, but is a worthwhile tradeoff for security and functionality, including support for ws-security. It has, however, been mostly eclipsed by REST.
REST is an architectural style which defines a set of architectural constraints for stateless communication between Application Programming Interfaces, or APIs. It is not a standard, so it allows developers some flexibility, but it acts as a mediator between users, clients, and resources. REST has become ubiquitous in API programming because it emphasizes scalability and greater interoperability, while its predecessor was a highly-structured protocol that required XML.
REST offers a number of constraints that make life easier for developers while still providing functionality and security.
REST in many ways iterated on SOAP to solve its inherent problems, and created a boom in web development as a result. They share similarities in the problems they solve, but they solve them differently.
REST now represents more than 70% of public APIs. If you don't have a compelling reason to use SOAP, use REST, because it's currently the biggest style in town. This means your API is most likely to play nicely with any API you might want to call, and be easy to use for other APIs calling yours. What compelling reasons might exist to use SOAP? There are still SOAP uses in finance and enterprise, where higher transactional reliability is required. SOAP also offers some more security features than REST, which may be required in certain use cases.
RESTful APIs solved a lot of problems with SOAP, and contributed to the explosion in web and cloud-native development. REST offers uniform interfaces, security by authentication, caching, and statelessness to developers. However, SOAP is not without its uses, offering more security tools and application logic control. Wondering about what happens after REST? Check out Graph-QL and gRPC for more information on the future of APIs beyond RESTful web services, and even beyond programming languages!