REST vs SOAP: The Decision Nobody Actually Makes Freely

"REST vs SOAP" gets framed as a design decision. In enterprise integration work, it's usually not — the protocol is dictated by whatever system sits on the other side of the wire.

The cases where it's not actually your choice

• A legacy SAP or mainframe system exposes a WSDL-defined SOAP contract. You're building a SOAP client, full stop.
• A modern SaaS platform only exposes REST/JSON. You're building a REST integration.

Most of the actual "decision" work in these cases is in the adapter layer: translating between the contract you're handed and the shape your own systems expect.

The cases where you do get to choose

The genuine decision shows up when you're the one exposing a new service — say, fronting an ERP with a contract for a new mobile app. Here, a few things tend to matter more than protocol preference:

• Contract stability requirements. SOAP's WSDL-first approach gives strong, machine-checkable contracts. REST can get there with a solid JSON Schema/OpenAPI discipline, but it takes more deliberate practice to enforce.
• Consumer expectations. A mobile or web front-end team will expect REST/JSON as a baseline; introducing SOAP there adds friction with no real benefit.
• Security requirements. WS-Security has more built-in machinery for message-level security than typical REST setups, which usually lean on transport-layer TLS plus OAuth2.

The practical takeaway

Don't treat this as a philosophical debate. Ask what's actually being integrated with, whether the contract needs to survive several client versions concurrently, and whether the security requirements go beyond what TLS and a bearer token can cover. The protocol falls out of those answers more often than it's chosen up front.