REST vs SOAP in SAP
When one system wants to request data or trigger an action in another system over the internet, it uses a web service. Two styles dominate the web service world: SOAP and REST. Both appear constantly in SAP integration. Understanding the difference — and knowing when to use each — is essential for every integration developer.
What Is SOAP
SOAP stands for Simple Object Access Protocol. It is a strict, formal protocol for calling web services. Every SOAP call uses XML, every SOAP call has a specific envelope structure, and every SOAP service has a formal contract document called a WSDL.
SOAP is like sending a registered letter through the postal service. There are strict rules: a specific envelope format, a tracking number, a signature on delivery, and a formal receipt returned to the sender. The process is well-documented and auditable, but it requires following every rule precisely.
SOAP Message Structure
<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">
<soap:Header>
<!-- Optional: authentication, transaction ID -->
<Auth><Token>abc123</Token></Auth>
</soap:Header>
<soap:Body>
<!-- The actual request -->
<GetCustomer>
<CustomerID>CUST-001</CustomerID>
</GetCustomer>
</soap:Body>
</soap:Envelope>
Every SOAP message has an Envelope (the outer wrapper), an optional Header (metadata like authentication tokens), and a Body (the actual request or response). This structure never changes regardless of the business content.
WSDL – The SOAP Contract
A WSDL (Web Services Description Language) document describes a SOAP service completely — every operation, every input parameter, every output parameter, and every data type. Before calling a SOAP service, you import its WSDL. CPI reads the WSDL and generates the correct message structure automatically.
What Is REST
REST stands for Representational State Transfer. It is not a protocol — it is an architectural style. REST uses standard HTTP methods (GET, POST, PUT, DELETE) and URLs to interact with resources. Data formats are flexible; JSON is most common, but XML and plain text also work.
REST is like shopping at a self-service store. You walk in (HTTP connection), pick up what you want (GET), add something to your cart (POST), update your order (PUT), or return an item (DELETE). The rules are minimal: use the right HTTP verb and the right URL. No formal contract document required.
REST HTTP Methods
METHOD PURPOSE EXAMPLE ────── ─────── ─────── GET Read data GET /customers/CUST-001 POST Create new data POST /customers (body: new customer JSON) PUT Update existing data PUT /customers/CUST-001 (body: updated JSON) PATCH Partial update PATCH /customers/CUST-001 (body: changed fields only) DELETE Remove data DELETE /customers/CUST-001
REST Response Codes
200 OK → Request succeeded, data returned 201 Created → New resource created successfully 400 Bad Request → Your request had an error (missing field, wrong format) 401 Unauthorized → Authentication failed (wrong API key or token) 403 Forbidden → Authenticated but not allowed to do this 404 Not Found → The requested resource does not exist 500 Server Error → Something failed on the server side
REST vs SOAP: Head-to-Head Comparison
┌─────────────────┬──────────────────────┬──────────────────────┐ │ Feature │ SOAP │ REST │ ├─────────────────┼──────────────────────┼──────────────────────┤ │ Protocol │ Formal protocol │ Architectural style │ │ Data Format │ XML only │ JSON, XML, text │ │ Contract │ WSDL required │ OpenAPI (optional) │ │ Security │ WS-Security (built-in│ OAuth, API Keys │ │ Transactions │ WS-AtomicTransaction │ Application level │ │ Verbosity │ Heavy (many wrappers)│ Lightweight │ │ Performance │ Slower (XML overhead)│ Faster │ │ Tooling │ Strong (mature) │ Growing rapidly │ │ SAP Usage │ Legacy systems, ABAP │ S/4HANA, BTP, cloud │ │ │ web services │ OData APIs │ └─────────────────┴──────────────────────┴──────────────────────┘
SOAP in SAP Contexts
SAP has used SOAP for many years. You encounter SOAP in:
- SAP Process Integration (PI/PO) – Many legacy integrations use SOAP adapters
- SAP Web Service Framework (ABAP) – ABAP developers expose business logic as SOAP web services
- B2B partner integrations – Industries like banking and healthcare have established SOAP-based standards (e.g., SWIFT, HL7)
- Older SAP APIs – Some SAP product APIs from the 2000s and 2010s use SOAP
REST in SAP Contexts
Modern SAP systems prefer REST:
- SAP S/4HANA OData APIs – OData is a REST-based protocol. All S/4HANA APIs are OData.
- SAP BTP services – All BTP services expose REST APIs
- SAP SuccessFactors – HR cloud APIs use REST/OData
- SAP Ariba, Concur, Commerce Cloud – All modern SAP cloud products use REST
OData: REST With SAP Flavoring
OData (Open Data Protocol) is a specific REST standard that SAP adopted for all its modern APIs. OData adds conventions that plain REST lacks — standard filtering, sorting, pagination, and relationship navigation. SAP S/4HANA exposes over 2,500 OData services covering every business object.
OData URL examples:
/sap/opu/odata/sap/API_SALES_ORDER_SRV/A_SalesOrder
→ List all sales orders
/sap/opu/odata/sap/API_SALES_ORDER_SRV/A_SalesOrder('100001')
→ Get specific sales order 100001
/sap/opu/odata/sap/API_SALES_ORDER_SRV/A_SalesOrder?$filter=SalesOrderType eq 'OR'
→ Filter only standard orders
/sap/opu/odata/sap/API_SALES_ORDER_SRV/A_SalesOrder?$top=10&$skip=20
→ Pagination: records 21-30
CPI Adapters for REST and SOAP
CPI provides dedicated adapters for both:
- SOAP Adapter – Send and receive SOAP messages. Import a WSDL to automatically configure the message structure.
- HTTP Adapter – Send REST HTTP requests. Configure the method (GET, POST, etc.), URL, headers, and authentication.
- OData Adapter – Specialized adapter for OData V2 and V4 APIs. Handles OData-specific features like $filter, $expand, and batch requests.
Choosing the right adapter depends on what the target system expects. A modern SAP S/4HANA connection uses the OData adapter. A legacy SAP system exposing an ABAP web service uses the SOAP adapter. A third-party REST API uses the HTTP adapter.