Choose by contract and operating constraints

REST and SOAP are not a modern-versus-legacy contest. The useful question is which contract, security profile, tooling ecosystem, message governance, and operational constraints the integration must satisfy. Financial systems often keep SOAP where formal schemas and WS-* capabilities are embedded in vendor contracts, while REST is common for simpler web-facing APIs.

Where REST and SOAP differ materially

  • SOAP defines an XML envelope and commonly uses WSDL for a formal service contract.
  • REST is an architectural style usually mapped to HTTP resources, methods, status codes, and JSON.
  • Transport security alone does not decide the protocol; message-level requirements and intermediary behavior may matter.
  • Versioning, timeout, retry, idempotency, audit, and schema validation are required in either approach.
  • An internal canonical model can isolate business code from both protocol formats.

Two protocol paths to the same business service

REST and SOAP terminate at separate adapters, then map into the same validated command and domain service. The choice stays at the boundary instead of spreading through business code.

Diagram

Protocol adapters around one business model

REST and SOAP terminate at separate adapters, then map into the same validated command and domain service. The choice stays at the boundary instead of spreading through business code.

REST and SOAP at the boundary

REST
  • Resource-oriented HTTP interface
  • Often JSON with lightweight client tooling
  • Flexible web/mobile consumption
SOAP
  • Formal XML envelope and WSDL contracts
  • Strong vendor tooling in many enterprise stacks
  • Message-level standards may be contractual

A bank integration decision

Misleading protocol arguments

Decision checklist

  • List contract, schema, security, and vendor constraints.
  • Define canonical request and response models.
  • Map protocol errors to stable business/API errors.
  • Set timeout, retry, and idempotency rules per operation.
  • Contract-test both adapters with representative fault responses.