Overview
This answer explains the core differences between SOAP and REST for interview scenarios. It covers architecture, message formats, security, state management, tooling, performance, and typical use-cases — useful keywords: SOAP vs REST, web services, API differences, Salesforce integration.
1. Architectural style
SOAP (Simple Object Access Protocol) is a protocol with a strict standard and formal specification. REST (Representational State Transfer) is an architectural style that leverages existing web standards (HTTP) and is more lightweight and flexible.
2. Message format
SOAP messages are XML-based and follow a strict envelope structure. REST can use multiple formats — JSON, XML, plain text, or even binary. JSON is most common for REST because of its compactness and native support in javascript.
3. Transport and operations
SOAP is transport-agnostic (HTTP, SMTP, TCP), but most commonly used over HTTP. REST relies on HTTP methods and resources — GET, POST, PUT, PATCH, DELETE — and uses URIs to identify resources.
GET /accounts/123 — retrieve account 123
POST /accounts — create account
PUT /accounts/123 — replace account 123
PATCH /accounts/123 — partial update
DELETE /accounts/123 — delete account 123
4. State management
REST is stateless — each request contains all information needed to process it. SOAP can support stateful operations via WS-* standards or by maintaining session state on the server.
5. Standards and extensibility
SOAP has a rich set of WS-* standards (WS-Security, WS-Addressing, WS-ReliableMessaging) for advanced enterprise needs like federation, transactions, reliable delivery, and message-level security. REST does not define standards at this level — functionality is implemented using HTTP headers, tokens (OAuth), and custom conventions.
6. Security
SOAP provides built-in message-level security (WS-Security) for signing and encrypting parts of the message. REST typically relies on transport-level security (HTTPS/TLS) and token-based authentication (OAuth, JWT). Choose SOAP when you need message-level security or advanced WS-* features.
7. Tooling and contracts
SOAP uses WSDL (Web Services Description Language) to describe service contracts, enabling strong typing and code generation for clients. REST may use OpenAPI/Swagger or RAML for documentation and client generation, but contracts are generally lighter and more flexible.
8. Performance and payload
REST with JSON usually results in smaller, faster payloads and lower parsing overhead. SOAP XML payloads are larger and more verbose, and parsing can be heavier — an important consideration for mobile or high-throughput systems.
9. Use-cases
Use SOAP when you require strict contracts, formal standards, WS-* features, or interoperable enterprise integrations with advanced security/transaction guarantees. Use REST for web APIs, microservices, mobile and browser clients, and when you want simplicity and performance.
10. Example — Salesforce context
Salesforce supports both SOAP API and REST API. The SOAP API provides a strongly-typed WSDL suitable for enterprise integrations and complex metadata operations. The REST API is lighter, uses JSON, and is preferred for mobile applications, AJAX clients, and lightweight integrations.
Quick comparison table (summary)
SOAP: Protocol, XML, WSDL, WS-* standards, message-level security, heavier payloads.
REST: Architectural style, JSON/XML, OpenAPI optional, relies on HTTP, simpler auth (OAuth/JWT), lightweight.
Common interview tips
– Start with definitions, then compare on format, transport, security, and use-cases.
– Mention Salesforce-specific examples if the role targets Salesforce integrations.
– Be ready to justify when to choose one over the other (e.g., need for WS-Security & transactions & formal contract => SOAP).