Monday, 29 October 2012

SOAP vs REST web services

Comparing SOAP to REST for building web services is a bit like comparing apples with pears: SOAP is a protocol, REST is a pattern, and you could, if you felt so inclined, write RESTful services using SOAP.  However, when people ask this question, they usually mean: SOAP (as in WSDL, perhaps RPC style, WS-* standards), as opposed to REST (as in JSON/XML over HTTP)

Assuming you mean this, below are some pros and cons for each, but note this: REST is increasingly becoming the de-facto standard across the web, being used by the big public API providers in preference to SOAP. I reckon it's just a matter of time before this question will just go away.



  • Language, platform, and transport agnostic
  • Designed to handle distributed computing environments
  • Is (or at least was) the prevailing standard for web services, and hence has better support from other standards (WSDL, WS-*) and tooling from vendors
  • Built-in error handling (faults)
  • Extensibility


  • Conceptually more difficult, more "heavy-weight" than REST
  • More verbose
  • Harder to develop, requires tools



  • Language and platform agnostic
  • Much simpler/intuitive to develop than SOAP
  • Small learning curve, less reliance on tools
  • Concise, no need for additional messaging layer
  • Closer in design and philosophy to the Web


  • Assumes a point-to-point communication model, so not usable for distributed computing environment where message may go through one or more intermediaries
  • Lack of standards support for security, policy, reliable messaging, etc., so services that have more sophisticated requirements are harder to develop ("roll your own")
  • Usually tied to the HTTP transport model