SOAP vs REST, when to use one and not the other?

Question

I\'m really confused everytime I come around this question, what characteristics would help one choosing SOAP over REST or the other way around?

I mean, besides the

Answer 1

SOAP is a form of RPC and REST is architecture style that can scale with the web.

REST concerns about the following (copied from RESTful Web Services)

• Addressability
• Statelessness
• Representations
• Links and Connectedness
• The Uniform Interface

Two great books on REST and have some discussions on the topic that you are interested in.

• REST in Practice
• Restful Web Services

Answer 2

If you just want a simple, visual guide to help you measure SOAP and REST against your applications requirements...

Vijay Prasad Gupta has put together a simple, helpful flow-chart.

Direct link to flow chart: https://drive.google.com/file/d/0B3zMtAq1Rf-sdVFNdThvNmZWRGc/edit

Link to article: https://www.linkedin.com/pulse/20140818062318-7933571-soap-vs-rest-flowchart-to-determine-the-right-web-services-protocol-for-your-needs

Answer 3

The difference between REST and SOAP is fundamental, yet they're not that dissimilar. Ultimately, you still need to transfer exactly the same information in order to perform a particular abstract operation. It's entirely easy to make REST rather low-performing by choosing poorly what information to return, and SOAP with MTOM can transfer large binary chunks efficiently. There's even the possibility to use non-XML encodings and connected transports (e.g., XMPP) with SOAP that can make it more efficient than REST.

So don't worry about that!

A much more relevant thing to think about is that SOAP continues to have significantly more advanced tooling support in some languages, and that other languages strongly prefer REST. For example, if you want a Java client for your service, you'll be able to get going with SOAP in minutes: just put the WSDL location through a tooling engine and you've got yourself a basic client. On the other hand, if you're working with a Javascript client then you'll absolutely prefer to deal with the REST interface; Javascript works great with REST.

A key thing to note here is that you can have your service support both SOAP and REST at once (you might need to put them on different endpoints, but that's not very onerous). I do this with a service I support (using Java and Apache CXF) and the overhead of doing both is minimal: the key is that I need a clean abstract interface behind the scenes that both the SOAP and REST interfaces use.