SOAP is a standard protocol that was first designed so that applications built with different languages and on different platforms could communicate. Because it is a protocol, it imposes built-in rules that increase its complexity and overhead, which can lead to longer page load times. However, these standards also offer built-in compliances that can make it preferable for enterprise scenarios. The built-in compliance standards include security, atomicity, consistency, isolation, and durability (ACID), which is a set of properties for ensuring reliable database transactions.
Common web service specifications include:
- Web services security (WS-security) : Standardizes how messages are secured and transferred through unique identifiers called tokens.
- WS-Reliable Messaging : Standardizes error handling between messages transferred across unreliable IT infrastructure.
- Web services addressing (WS-addressing) : Packages routing information as metadata within SOAP headers, instead of maintaining such information deeper within the network.
- Web services description language (WSDL) : Describes what a web service does, and where that service begins and ends.
When a request for data is sent to a SOAP API, it can be handled through any of the application layer protocols: HTTP (for web browsers), SMTP (for email), TCP, and others. However, once a request is received, return SOAP messages must be returned as XML documents—a markup language that is both human- and machine-readable. A completed request to a SOAP API is not cacheable by a browser, so it cannot be accessed later without resending to the API.
A SOAP message is enclosed in a SOAP envelope that contains a SOAP header and a SOAP body. The SOAP body is mandatory, whereas the SOAP header is optional. The SOAP message is the basic unit of communication between SOAP nodes.