Most articles on this compare the two as if you were starting a greenfield project and got to pick. On an integration project you almost never do. The system on the other side was built years ago by someone who has left, and it exposes what it exposes. The real question is not which is better - it is what each one costs you once the choice has been made for you.
The one-line version
SOAP is a protocol: a fixed XML envelope, a machine-readable contract, and an error format everyone agrees on. REST is an architectural style: resources addressed by URL, manipulated with HTTP verbs, usually carrying JSON. SOAP tells you what a message must look like. REST tells you how to think about your API and leaves the rest to you.
That single difference - a specification versus a set of conventions - explains almost everything else that follows.
Where you still meet SOAP
SOAP is not a historical curiosity. In the integrations we are asked to build, it turns up reliably in the same places:
- Core banking and insurance platforms, where the interface was certified once and changing it means recertifying.
- Telco OSS/BSS stacks.
- SAP, which exposes plenty of SOAP alongside its newer OData surface.
- Public-sector registries and anything that had to satisfy a procurement document written before 2015.
What those have in common is not age. It is that somebody signed off on the interface contract and the cost of reopening that decision is higher than the cost of speaking XML.
What SOAP actually gives you
Three things, and it is worth being honest that they are real advantages rather than legacy baggage.
A contract you can generate a client from. A WSDL describes every operation, every type and every fault. Point a tooling stack at it and you get a typed client without writing a line. REST's equivalent is OpenAPI - but OpenAPI is optional, frequently written after the fact, and in our experience frequently wrong. A WSDL that disagrees with the service is a bug someone will fix. An OpenAPI file that disagrees with the service is Tuesday.
Message-level security. WS-Security signs and encrypts the message itself, so it stays protected across intermediaries. TLS protects one hop. If your payload passes through a broker, an ESB and a partner gateway before it lands, that distinction stops being academic.
A defined error shape. SOAP Fault means every service fails the same way. With REST you get whatever the team decided - a 200 with an error object inside, a 500 with an HTML page, or a 400 with a message in a field called msg, message or error depending on which developer wrote the endpoint.
What REST gives you
Everything the last twenty years of tooling assumes. You can call it from a browser, a shell, a mobile app or an automation platform with no client library. Payloads are smaller and readable without a decoder ring. Caching works the way HTTP always meant it to. And the learning curve is short enough that you can hand an endpoint to someone who has never seen your system and expect them to succeed.
For anything public-facing, anything mobile, anything you want a partner to integrate against without a two-week onboarding, REST is not a preference. It is the only sensible answer.
What actually costs you time
Here is the part the comparison articles leave out. On the projects we deliver, the protocol is rarely what makes an integration expensive. Three other things are.
Contract discipline. Whether the contract lives in a WSDL, an OpenAPI file or a Confluence page nobody updates, the failure is the same: the interface changes and the consumer finds out in production. SOAP makes the contract harder to ignore, which is an accident of format rather than a virtue of the protocol.
Idempotency and retries. Networks fail mid-call. If the receiving system cannot tell a retry from a second request, you will eventually create duplicate orders, duplicate tickets or duplicate payments. SOAP gives you WS-ReliableMessaging and WS-AtomicTransaction; REST gives you nothing and expects you to build it. Neither is free, and in both cases skipping it is the single most common integration defect we are called in to fix.
Error semantics. Not the format - the meaning. Is this failure retryable? Is it the caller's fault or the callee's? Should a human look at it? Teams argue about JSON versus XML and then ship an integration where every failure looks identical to the operations team.
So which one
If the other side has already decided, they have decided. Build against what exists and spend your effort on the three things above.
If you genuinely have the choice, REST, unless you can name a specific reason not to - message-level security across intermediaries, a transaction that must span systems, or a partner whose tooling only speaks WSDL. Those reasons are rarer than they were, and they are still real.
And if you are looking at a working SOAP integration and wondering whether to modernise it: usually not. Rewriting an interface that works, to change its message format, is a project with a cost and no user-visible benefit. Do it when you are changing the system behind it anyway, not as an end in itself.
A note on the two platforms we work in most
ServiceNow treats both as first-class - SOAP Message and REST Message records, with IntegrationHub spokes on top for the systems that have one. BMC Remedy's AR System likewise exposes both. Neither platform will push you toward one, which means the decision comes back to the other side's interface and to the three costs above.
We build and untangle these integrations for a living. If you have one that keeps producing duplicates, or an interface contract nobody trusts, tell us what you are connecting.