What is the core difference between SOAP and REST, and why is comparing the two not quite like-for-like?
answer
- protocol versus architectural style
- an envelope versus a resource
- HTTP as transport or as application
- contract published or optional
- XML always, JSON usually
basics
~20 sSOAP is a messaging protocol: an XML envelope carrying operations, usually described by a WSDL contract, over HTTP or other transports. REST is an architectural style: resources at URIs, acted on through HTTP's uniform methods and status codes.
solid answer
~40 sSOAP is a W3C protocol: every message is an XML `Envelope` with an optional `Header` and a mandatory `Body`, it can travel over HTTP or other underlying protocols, and services usually publish a WSDL contract that tools turn into client stubs. REST is not a protocol at all but an architectural style, described in Roy Fielding's 2000 dissertation: you model resources, give each a URI and act on them through HTTP's standard methods, so status codes, caches and intermediaries do part of the work. That is why the honest comparison is "SOAP over HTTP" against "resource-oriented HTTP, usually with JSON". SOAP brings a formal contract, one fixed message format and the WS-* extensions for message-level security and reliability; REST brings HTTP's own semantics, cacheable reads and lighter tooling.
go deeper
Lead with the category difference: SOAP is a protocol with an XML envelope, REST is an architectural style built on HTTP's methods, URIs and status codes.
Compare on named axes - contract, errors, caching, security, transport - and correct the usual myths: REST is not JSON-only, SOAP is not HTTP-only.
Show where each wins in production: SOAP where a partner's contract or message-level protection decides, REST where HTTP caching, tooling and broad client reach matter.
Frame it as an ecosystem choice: who owns the contract, what partners already run, and what each style costs to evolve across many consumers over years.
## Two different kinds of thing The question "SOAP or REST?" compares a **protocol** with an **architectural style**, and a strong answer starts by saying so. - **SOAP** is a messaging protocol. SOAP 1.1 was published as a W3C Note in 2000; SOAP 1.2 is a W3C Recommendation (second edition 2007) that describes itself as "a lightweight protocol intended for exchanging structured information in a decentralized, distributed environment". It defines a message format and the rules a node follows when it receives one. - **REST** (Representational State Transfer) is a set of architectural constraints described in Roy Fielding's 2000 doctoral dissertation. It does not define a message format. On the Web it is realised through HTTP, whose specification (RFC 9110) cites REST when it explains why HTTP methods are not resource-specific: a **uniform interface** gives "better visibility and reuse in network-based systems". So the comparison people actually mean is **SOAP carried over HTTP** against **an HTTP API designed around resources**, usually exchanging JSON. ## What SOAP defines - **The envelope.** Every SOAP message is an XML `Envelope` holding an optional `Header` and a mandatory `Body`. The envelope's namespace tells the receiver which SOAP version it is reading. - **A processing model.** Header blocks can be aimed at intermediaries, and a block marked as mandatory must be understood or the message is refused with a fault. - **Faults.** Errors travel as a `Fault` element inside the Body. - **Bindings.** SOAP 1.2 is built to run over "a variety of underlying protocols". Its only normative binding is HTTP, and a separate W3C Recommendation, SOAP over Java Message Service 1.0, carries the same envelope over message queues. - **Deliberate gaps.** SOAP 1.2 leaves out "reliability", "security", "correlation" and "routing". Those come from the **WS-*** specifications - WS-Security, WS-Addressing, WS-ReliableMessaging and others - which ride in header blocks. The contract usually comes from a separate specification, **WSDL**. SOAP itself does not require one, but nearly every SOAP service publishes a WSDL document, and client tools generate typed stubs from it. ## What REST means on HTTP - **Resources and URIs.** Each thing the API exposes - an order, a policy, a filing - has its own URI. - **The uniform interface.** `GET`, `PUT`, `POST`, `DELETE` and the others mean the same thing on every resource, so clients, proxies and caches understand a request without knowing the application. - **Status codes as the outcome.** A 404 or a 503 is understood by any HTTP component. - **Representations.** JSON is common, but REST does not prescribe a format; XML representations are just as legitimate. - **Contract optional.** Many REST APIs publish an OpenAPI description, but HTTP does not require one. ## Side by side | Concern | SOAP over HTTP | Resource-oriented HTTP (REST) | |---|---|---| | Message format | Always an XML envelope | Any media type; JSON is common | | What the URI names | An endpoint that accepts many operations | One resource | | How the action is chosen | Operation element in the Body (plus a SOAPAction hint) | The HTTP method | | Contract | WSDL with XML Schema, near universal | Optional; an OpenAPI description is common | | Errors | `Fault` element in the Body | HTTP status code plus a body | | Security | TLS, optionally WS-Security in the header | TLS plus tokens in HTTP headers | | Caching | Effectively none: nearly every call is a `POST` | HTTP caching for `GET` | | Transports | HTTP, message queues | HTTP | ## How to answer in an interview 1. Name the category difference: protocol against style. 2. Compare on concrete axes - contract, errors, security, caching, payload and tooling cost. 3. Say when SOAP still wins: a counterpart's mandate, a formal contract shared by many partners, protection that must survive intermediaries, or a non-HTTP transport. 4. Say when REST wins: public and browser-facing APIs, cache-heavy reads, teams that want plain HTTP tooling. ## Common confusions - "REST means JSON" - the format is a choice, not a constraint. - "SOAP is only for HTTP" - the binding framework exists precisely so it is not. - "Any non-SOAP HTTP API is REST" - an API that posts every call to one URL with a JSON body is RPC over HTTP, not REST. - "SOAP is dead" - it remains the incumbent in many banking, insurance, government and healthcare integrations, where the partner's contract decides. Interviewers rarely want a verdict; they want to hear the candidate weigh both sides on named, checkable points rather than reach for a reflex.
- Does SOAP require a WSDL document, and does REST require JSON?Neither. SOAP 1.2 defines the envelope, processing model and bindings; WSDL is a separate W3C specification that SOAP does not mandate, although almost every SOAP service publishes one because client tools generate stubs from it. REST constrains the architecture, not the format: JSON is popular, but XML or any other media type can serve as a resource's representation.
- Can SOAP run without HTTP at all?Yes. SOAP 1.2 defines a binding framework so the same envelope can travel over different underlying protocols; its only normative binding is HTTP, and the W3C's SOAP over Java Message Service 1.0 carries it over message queues. A REST API, by contrast, depends on HTTP's uniform interface - its methods and status codes are the design.
- Is SOAP stateful and REST stateless?No. The SOAP 1.2 Primer calls SOAP "fundamentally a stateless, one-way message exchange paradigm"; richer patterns such as request-response are built on top. Statelessness of each request is one of REST's architectural constraints, but neither style forces an application to keep or avoid server-side state.
saying these in an interview costs you the question
- SOAP and REST are both protocols that differ only in message format.
- REST means JSON, so an API returning XML cannot be RESTful.
- SOAP only works over HTTP.
- Any HTTP API that is not SOAP is automatically REST.
- The SOAP specification itself provides security and reliable delivery.
- SOAP is obsolete and never the right choice for a new integration.