Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

As far as I can see consuming SOAP requires a SOAP stack, so it is harder for your clients to consume i.e. they need to ensure that they have a SOAP stack in place that formats the POST data and the headers correctly and then gives you back some data structure, whereas with REST you just make an HTTP GET request with the arguments in the query string and get back some text that I guess is probably XML.

So what does the extra overhead / complexity of SOAP give you, when do you need it and when could you and should you do without it?

share|improve this question

6 Answers 6

up vote 10 down vote accepted

I have implemented a REST API before and I really liked it. In general when you implement REST over SOAP, your client/server is more orthogonal meaning that you can a lot more freely change the server without affecting your client(s). This orthogonality is due to using a more abstract and already well defined communication via HTTP verbs. Also, the use of hyperlinks embedded in your REST responses make it easier to extend and grow your API relatively pain free. Clients are supposed to follow these embedded links to get to new resources like a human would follow links on a webpage to 'drill down' for more information.

With that said, I had some coworkers who were told they had to use SOAP and they complained about it all the time. So I went into researching the two a bit more in detail.

In general what I found is that REST is well suited for highly distributed applications, when you have hundreds, thousands or millions of clients. One reason is the above mentioned orthogonality, another is caching that you get for free since you are using HTTP.

SOAP might be the quicker way to go when you need a smaller API for a client or two quickly and you are not too worried about scalability. It might also fit you better if you do not have an architecture that is structured around resources, because it might take you some time to restructure your app to even be able to implement REST.

share|improve this answer
You get caching because of the resource paradigm and lack of state, not because of HTTP. –  dietbuddha Oct 3 '11 at 0:45

It might be a minor point, but REST is entirely based on HTTP.

SOAP does not require HTTP, and you are free to use whatever transport you like.

SOAP messages can be routed asynchronously and reliably whereas REST is pretty much a synchronous paradigm.

REST does not tell you anything about what the data you are sending and receiving should look like. There is WADL, but mostly you rely on documentation of the API being correct. SOAP has circus of XML technologies to make data description less error prone. WSDL, Schema...

At the end of the day REST basically gets you a file system based on HTTP. If your system can fit into that paradigm - then it might be a good choice.

share|improve this answer
+1 for mentioning multiple transports. If you really need a transport-agnostic protocol (which e.g. supports operation via SMTP or similar), REST is out. Usually HTTP is good enough, however... –  sleske Mar 23 '12 at 19:00

REST uses post as well. In-fact when using REST the http verbs tell you what operation is going on.

REST and SOAP are just different standards of passing data over the internet.

Having used both I would generally recommend using REST rather than SOAP unless you know the people who are going to consume your web service are using .net and Visual Studio. Its generally much easier to consume a REST web service except with .net VS which does most of the work for you when your using SOAP.

share|improve this answer
There is good SOAP support in Java, too. –  user1249 Oct 2 '11 at 16:17

One thing I would mention is interoperability - if you're going to call your service from an app written in .NET and the server is written in Java (or any other combination) then go for REST. I've seen too many slight incompatibilities between SOAP implementations to bother considering it any more.

share|improve this answer
Agree. SOAP is industry standard but overly complex, resulting in tons of broken or incomplete implementations. On top of it, SOAP has typically the largest footprint with regard to performance and traffic compared with any other approach. –  JensG Oct 6 '13 at 21:33

So what does the extra overhead / complexity of SOAP give you, when do you need it and when could you and should you do without it?

The biggest difference between the two is that REST is suppose to be stateless, where-as SOAP is not. In practice many REST implementation actually do implement some state in the session through something like OAuth.

Another difference is REST is very "resource" or noun oriented. You interact with resources through CRUD operations. Anything that doesn't fit this paradigm becomes cumbersome and awkward.

SOAP on the other hand is just an RPC (remote procedure call) protocol. It doesn't come with a paradigm, it's just the transport layer.

share|improve this answer
Both SOAP and REST are only means to achieve an end result. They may or may not be suitable for the task. So REST too can be seen as a transport layer. Even the state/less view does not hold: you can design both flavours with both - and other - types of APIs. You can even have an dual API, which has both a SOAP and a REST endpoint. And an XML-RPC endpoint. And an Apache Thrift endpoint. And an Google Protocol Buffers endpoint. And what else. At the end of the day everything is just an RPC. –  JensG Oct 6 '13 at 1:30

It is now 2015. I would have hoped that SOAP has died by now, but it still lingers like a bad smell. For anything but the most basic of "example" applications, integrating with a SOAP service is frought with challenges. It is a complex architecture, with many options at multiple levels, combined with the quirks of multiple implementations and subtle (and not so subtle) incompatibilities. I've never had a single good experience with it. REST, on the other hand, is a breeze: everyone understands HTTP. For most cases, JSON has so muh more utility than XML InfoSet.

To give you an idea of the complexity of SOAP, try integrating a SOAP library into your project. For Java, the most basic Apache Axis2 client (using simple ADB data binding) pulls in 23 new JARs. Twenty three! 20MB of library bloat. CXF is similar: 21 JARs, when I last counted.

If you really wanted to, you can do REST with a simple HTTP library.

share|improve this answer
this reads more like a rant, see How to Answer –  gnat Feb 26 at 15:37
You're right. Sorry, I was awash in SOAP soup at the time :D –  Cornel Masson Mar 25 at 13:56

protected by gnat Feb 26 at 15:37

Thank you for your interest in this question. Because it has attracted low-quality answers, posting an answer now requires 10 reputation on this site.

Would you like to answer one of these unanswered questions instead?