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

5 Answers 5

up vote 5 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
3  
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

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.