32

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?

Improve this question

7 Answers 7

Reset to default
18

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.

Improve this answer
2
  • 2
    You get caching because of the resource paradigm and lack of state, not because of HTTP.
    – snakehiss
    Commented Oct 3, 2011 at 0:45
  • 1
    @dietbuddha HTTP does give you the implementation for free.
    – Jacob is on Codidact
    Commented Jul 7, 2017 at 8:38
18

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.

Improve this answer
3
  • +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
    Commented Mar 23, 2012 at 19:00
  • 6
    I don't see how REST is tied to HTTP? That's implementation detail. Most REST implementations go over HTTP, but I don't see why I couldn't implement REST over other protocols, like FTP.
    – edalorzo
    Commented May 26, 2015 at 19:42
  • 1
    REST does not restrict communication to a particular protocol ref: ics.uci.edu/~fielding/pubs/dissertation/rest_arch_style.htm
    – nmtoken
    Commented Jun 23, 2015 at 13:05
8

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.

Improve this answer
1
  • 1
    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
    Commented Oct 6, 2013 at 1:30
5

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.

Improve this answer
1
  • 4
    There is good SOAP support in Java, too.
    – user1249
    Commented Oct 2, 2011 at 16:17
5

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.

Improve this answer
1
  • 2
    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
    Commented Oct 6, 2013 at 21:33
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

Improve this answer
1
  • That's actually a pretty decent flowchart. I was surprised that not a single answer in here addresses the advantages of SOAP over REST. That flowchart does though. I think I might include the flowchart as an image here instead of linking to it though, just to make sure it sticks with the answer?
    – jleach
    Commented Jul 7, 2017 at 14:00
-2

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.

Improve this answer
4
  • 1
    this reads more like a rant, see How to Answer
    – gnat
    Commented Feb 26, 2015 at 15:37
  • You're right. Sorry, I was awash in SOAP soup at the time :D
    – Cornel Masson
    Commented Mar 25, 2015 at 13:56
  • 1
    We had the same complaint with CORBA/IDL back in the 90s. Then suddenly "Simple Object Access Protocol" .. it will be simple! It will be cool! It will be fast. Ten years later, it is considered too complex. Along comes JSON (IMAO really a square wheel for data transfer operations in student lab settings or restricted "I know what I'm doing" quick fix situations) and RESTful ops. Rinse, repeat...
    – David Tonhofer
    Commented Nov 22, 2016 at 12:38
  • I'm afraid every true statement about SOAP must read as a rant. It's enterprisey by design and gives you tons of options where you just want to send some data. Concerning the few SOAP interfaces I worked with, each was a highly redundant mess (not exactly SOAP's fault, but the affinity to SOAP correlates with the affinity to bloatware). Sorry for ranting.
    – maaartinus
    Commented Nov 23, 2016 at 7:07