REST vs SOAP is the choice between two ways of building and calling web services. REST (Representational State Transfer) is an architectural style: it uses standard HTTP methods like GET and POST on resource URLs and usually exchanges JSON. SOAP (Simple Object Access Protocol) is a formal protocol: every message is an XML envelope, and the service is described by a WSDL contract that defines exactly what can be sent and returned.
For new APIs, REST has largely won. For integration teams, though, the question is rarely which to build. It's how to connect the REST APIs of modern SaaS tools with the SOAP services still running core systems. This guide compares the two and covers what that means for integration work.
What REST is
REST treats everything as a resource with a URL, such as /customers/42, and uses HTTP methods to act on it: GET to read, POST to create, PUT or PATCH to update, DELETE to remove. Responses are usually JSON, and each request carries everything needed to process it.
- Lightweight: small payloads and simple tooling; any language with an HTTP client can call it.
- Flexible: no mandatory contract, though most teams describe REST APIs with OpenAPI.
- Cache-friendly and stateless: it fits web, mobile, and cloud services well.
Salesforce, Stripe, Shopify, Slack, and almost every modern SaaS product expose REST APIs.
What SOAP is
SOAP defines a message format and rules. Each request and response is an XML envelope with a header and body, and the WSDL (Web Services Description Language) file describes every operation, data type, and endpoint. The WS-* standards add capabilities such as message-level security (WS-Security) and reliable messaging.
- Strict contract: the WSDL defines exactly what's valid, which tools use to generate client code.
- Built-in standards: message signing, encryption, and transaction support.
- Heavier: verbose XML, more processing, and more complex tooling.
SOAP is common in SAP and Oracle back-office systems, core banking, insurance policy platforms, telecom billing, payroll providers, and government services.
REST vs SOAP compared
| REST | SOAP | |
|---|---|---|
| Type | Architectural style | Protocol with a formal specification |
| Message format | Usually JSON (also XML, others) | XML envelope only |
| Contract | Optional (often OpenAPI) | Required (WSDL) |
| Transport | HTTP | Usually HTTP; can use others such as SMTP or JMS |
| Security | HTTPS plus OAuth 2.0 or API keys | HTTPS plus WS-Security message-level signing and encryption |
| Error handling | HTTP status codes and error bodies | SOAP Fault elements |
| Payload size and speed | Smaller and faster | Larger and slower to parse |
| Typical systems | SaaS, mobile, cloud services | ERP, banking, insurance, telecom, government |
When SOAP is still the right fit
- The system only offers SOAP. Many core systems do, and replacing them isn't on the table.
- Message-level security is required. WS-Security can sign and encrypt parts of a message, which some banking and government interfaces mandate.
- A strict contract is valuable. In formal partner integrations, the WSDL makes expectations unambiguous.
- Existing tooling depends on it. Teams with mature SOAP clients and test suites may not gain from rewriting them.
Integrating REST and SOAP systems together
Most enterprise integrations cross the line. A typical example: an order is created in Shopify (REST, JSON), then posted to an ERP that accepts orders through a SOAP service (XML), and the invoice number is sent back to Shopify.
What that integration has to handle:
- Format translation: map JSON fields to the XML elements the WSDL expects, including namespaces and data types.
- Authentication on both sides: OAuth tokens for the REST side; often username tokens, certificates, or WS-Security for SOAP.
- Errors in two styles: translate SOAP Faults and HTTP error codes into one consistent way of retrying and reporting.
- Contract changes: keep the WSDL and OpenAPI definitions under version control, so a change on either side is caught before it breaks production.
Choosing for a new API
If you're designing a new API, REST with an OpenAPI description is the default for most use cases, because it's easier for partners and developers to adopt. Consider SOAP only when a partner or regulation requires it, or when you're extending an existing SOAP service. GraphQL and gRPC are also options for specific needs (flexible queries, and high-performance internal services respectively), but they don't replace REST for general integration. For broader guidance, see building an API strategy.
Frequently asked questions
What is the main difference between REST and SOAP?
REST is an architectural style that uses standard HTTP methods on resource URLs and usually JSON. SOAP is a protocol that wraps every message in an XML envelope and requires a WSDL contract describing the service.
Is SOAP outdated?
It's rarely chosen for new public APIs, but it's far from gone. Many ERP, banking, insurance, telecom, and government systems still expose SOAP services, so integration teams work with it regularly.
Is REST more secure than SOAP?
Neither is inherently more secure. REST relies on HTTPS with OAuth 2.0 or API keys. SOAP can add WS-Security for message-level signing and encryption, which some regulated interfaces require.
Can a REST API call a SOAP service?
Yes. An integration layer can accept REST requests, translate them into SOAP XML that matches the WSDL, call the service, and translate the response back to JSON.
Should I use REST or SOAP for a new integration?
Use REST for new APIs and integrations in most cases. Use SOAP when the system or partner you're connecting to only offers SOAP or requires it.
Connect both worlds
Few enterprises get to choose between REST and SOAP; they have to connect both. To see Koodisi connect a REST SaaS app to a SOAP back-office system, working in JSON on both sides, book a demo.