What is Simple Object Access Protocol (SOAP)?
Thinking about SOAP APIs brings to mind a middle school taunt along the lines of “The 90s called. They want their pants back.” Revolutionary in its day, the technology can sometimes now feel dated. Yet, Simple Object Access Protocol (SOAP) has exhibited more staying power than many of its detractors would like to admit. If you’re involved in enterprise architecture or application integration, it pays to know a bit about the SOAP application programming interface (SOAP API)—where it came from, what it does, where it can be effective, and the vulnerabilities it can potentially create.
What is SOAP?
SOAP is a standards-based messaging protocol specification. SOAP messages exchange structured information using XML as its message format. With SOAP, an application can invoke a Web Service, send or retrieve data, or issue a procedure call. A SOAP message travels using application layer protocols like Hypertext Transport Protocol (HTTP), though it can also run on Simple Mail Transfer Protocol (SMTP), Java Message Service (JMS), and others.
The history of SOAP
To understand the importance of SOAP, it’s necessary to know what came before it and the problems its creators set out to solve. SOAP enables two or more applications, built in any language and running on any platform to exchange data and procedure calls across virtually any kind of network. This may not seem so special in 2022, but there was a time when the very idea of such interoperability would have seemed like science fiction.
Getting two or more computer systems to communicate and interoperate is a challenge that goes back at least to the early 1960s. And, while many innovative developments made it incrementally easier to achieve this goal, by the 1990s, many industry insiders had reached the conclusion that a radical change was needed. Interfaces between applications were either custom-coded or built using cumbersome proprietary middleware products. Companies spent fortunes and person-years managing these fragile connections and buying connector sets.
The answer was for the major industry players to come together and agree upon a set of open standards for application integration, data exchange, and interoperation. By 1998, these standards had come into existence and were ratified by the Internet Engineering Task Force (IETF). In addition to SOAP, these so-called “Web Services Standards” included Web Service Description Language (WSDL), which describes how a SOAP web service works, and Universal Description Discovery and Integration (UDDI), which is a format for a SOAP web service directory.
SOAP and its accompanying Web Services standards became the foundation for an entire generation of dominant enterprise technologies. The Web Services standards were the basis for the massive, entirely new Microsoft .NET framework, the Oracle Aquasoft platform and portfolio, IBM’s WebSphere integration platform and portfolio, SAP NetWeaver, and others. They represented a profound revolution in software development, application integration, and enterprise architecture.
SOAP's relationship to XML
SOAP messages are built in the Extensible Markup Language (XML). The SOAP standard specifies the XML schema used to create a SOAP message. This includes the “envelope” for the message, which defines the message structure and destination. The SOAP XML schema also includes encoding rules that represent data types, as well as a convention for representing procedure calls and responses.
When to use SOAP
SOAP is useful in a variety of situations. It is good when synchronous processing is occurring, perhaps coupled with the need to invoke certain APIs subsequently. SOAP is handy when it’s necessary for a server and client to exchange data in a structured format. SOAP is also effective for the seamless processing of stateful operations, i.e., when an application needs to maintain the state from one request to another. In some cases, there may be no choice but to use SOAP, e.g., when it’s the default integration protocol for a packaged application.
Differences between SOAP and REST
Use of SOAP and the Web Services standards has been in decline since the emergence of Representational State Transfer (REST) as the primary basis for APIs, data exchange, and application integration. There’s an idea that REST “replaced” SOAP. This is true, in a limited way, but it’s worth noting the differences between the two.
- SOAP is a protocol, in contrast to REST, which is an architectural pattern
- SOAP uses web services to expose functionality to clients, versus REST, which relies on URLs to access components of a REST service
- SOAP requires more bandwidth than REST
- SOAP cannot use REST, but REST can use SOAP
Advantages, limitations, and vulnerabilities of SOAP
SOAP has its good and bad points. The protocol’s advantages are well understood. With WSDL, for example, a developer gets the information he or she needs to develop and implement a SOAP API with relative ease. SOAP’s multiple extensions, like WS Addressing, WS Security, and WS Federation, are also helpful as pre-built app components.
On the downside, SOAP has proven itself to be comparatively complex and time-consuming compared to RESTful alternatives. The syntax tends to be challenging, for instance. Performance can be an issue with SOAP’s XML. And, while SOAP is theoretically vendor-neutral, implementing it often involves committing to a stack, such as Microsoft, which not everyone wants to do.
SOAP creates some distinctive cyber-risk exposure, as well. SOAP API security vulnerabilities include Denial of Service (DoS) attacks, XML injection (XXE), SQL injection, command injection, and more. SOAP is also vulnerable to spoofing and Man-in-the-Middle (MiTM) attacks. Web Services security tools can mitigate many of these risks.
Aging but still vital, SOAP has a role to play in modern application integration and interoperation. The protocol is favored over REST in many use cases. It will likely continue to serve as a critical element of enterprise architectures for a generation to come.