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.
SOAP
Pros:
- 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
Cons:
- Conceptually more difficult, more "heavy-weight" than REST
- More verbose
- Harder to develop, requires tools
REST
Pros:
- 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
Cons:
- 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