Brief Answer
- SOAP — protocol with formal contracts (WSDL), XML messages, and WS‑* extensions.
- REST — architectural style: resources, HTTP methods, statelessness, caching, clear status codes.
- SOAP fits strict integration and transactions; REST suits web APIs, fast development, and scaling.
- Formats: SOAP is usually XML; REST commonly JSON but supports any media type.
- Transport: SOAP can use multiple transports (HTTP, SMTP, etc.); REST relies on HTTP semantics.
Full Answer
Interaction model
- SOAP — operation‑centric: you call methods (operations) with strict contracts.
- REST — resource‑centric: you work with resources via HTTP (GET/POST/PUT/DELETE).
Contracts and typing
- SOAP uses WSDL/XSD — strict, formal contracts.
- REST is often described with OpenAPI/Swagger — less formal yet sufficient for clients and codegen.
- SOAP: XML envelopes, WS‑Security, WS‑ReliableMessaging, transactions.
- REST: flexible formats (JSON, XML, HAL), HTTP caching, ETag, content negotiation.
Errors and statuses
- SOAP: a
Fault element with codes/details in XML.
- REST: standard HTTP codes (
200, 201, 400, 404, 500) plus an error body.
When to choose
- Choose SOAP: strict compliance, transactional flows, enterprise buses, legacy integration.
- Choose REST: public APIs, microservices, web UIs, faster iteration.
Mini examples
REST:
GET /users/1
Accept: application/json
{"id":1}
SOAP:
<soap:Envelope>
<soap:Body>
<GetUser id="1"/>
</soap:Body>
</soap:Envelope>