# SOAP (Simple Object Access Protocol) SOAP (Simple Object Access Protocol) is a messaging protocol specification for exchanging structured information between systems in a networked environment. It uses XML as its message format and typically relies on HTTP or SMTP as the transport layer, though it is transport-agnostic by design. SOAP was one of the earliest standardized approaches to building web services and remains in use in enterprise and regulated environments. ## How SOAP works A SOAP message is an XML document with a defined structure consisting of an **Envelope** (the root element), an optional **Header** (for metadata such as authentication tokens or transaction identifiers), and a **Body** (containing the actual request or response payload). A **Fault** element within the body is used to report errors. Services that expose SOAP interfaces publish a WSDL (Web Services Description Language) file, which is an XML document describing the available operations, their input and output parameters, and the endpoint URLs. Clients use the WSDL to generate code stubs or to construct requests programmatically. ## SOAP vs. REST SOAP and REST represent different approaches to web service design: * **Message format**: SOAP mandates XML. REST commonly uses JSON but supports any format. * **Contract**: SOAP relies on a formal WSDL contract. REST APIs may use an OpenAPI specification but do not require one. * **Statefulness**: SOAP supports stateful operations through WS-\* extensions. REST is designed to be stateless. * **Overhead**: SOAP messages are larger due to the XML envelope structure and required namespaces. REST over JSON is more compact. * **Built-in standards**: SOAP has specifications for security (WS-Security), reliable messaging (WS-ReliableMessaging), and transactions (WS-AtomicTransaction). REST relies on transport-layer security (TLS) and application-level patterns. Many organizations still run SOAP services for internal or legacy systems while exposing REST or GraphQL APIs externally. An API gateway can sit between these worlds, accepting REST requests from clients and translating them into SOAP calls to the backend, or simply routing SOAP traffic while applying consistent security and monitoring policies. ## SOAP and API gateways API gateways often need to handle SOAP traffic alongside REST traffic. A gateway can validate SOAP messages, enforce WS-Security policies, route to different SOAP endpoints based on the SOAPAction header, and log or transform messages in transit. For organizations modernizing their architectures, the gateway can also serve as a translation layer, accepting modern REST/JSON requests and converting them to SOAP/XML for legacy backends. Serverless API Gateway supports HTTP-based routing and can proxy requests to SOAP backend services. The request and response bodies pass through the gateway, allowing teams to apply authentication, CORS, and path-based routing to SOAP endpoints just as they would for REST APIs. ## Related documentation * [Servers Configuration](/configuration/servers.md) - Configure upstream SOAP service endpoints * [Variable Mapping](/configuration/variable-mapping.md) - Map request variables between different formats * [Path Routing](/configuration/paths.md) - Route requests to SOAP and REST backends --- # Agent Instructions: Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter: ``` GET https://docs.serverlessapigateway.com/glossary/s/soap-simple-object-access-protocol.md?ask= ``` The question should be specific, self-contained, and written in natural language. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.