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.

From my understanding of REST, the implicit assumption is that all operations are CRUD operations. Sometimes, you are not doing CRUD operations and are doing some more complex logic. In this case, is not SOAP more suitable? Or is it the case that all operations no matter how complex are a series of CRUD operations so they should be split up into a set of smaller CRUD operations to be called one after the other? But, does this not make the operation you are attempting more cumbersome to write? I am trying to understand when it might make more sense to use SOAP instead of REST.

share|improve this question

marked as duplicate by gnat, Bart van Ingen Schenau, MichaelT, Florian Margaine, Dynamic Aug 6 '13 at 13:51

This question has been asked before and already has an answer. If those answers do not fully address your question, please ask a new question.

2  
In my experience, SOAP is used more as RPC-style, whereas REST is utilized for 'pure' object access. –  CodeCaster Jun 21 '13 at 10:39
5  
@maple_shaft: I disagree; "understandable" / "obscure" is subjective, but "simple" / "complex" is not. It may not be quantifyable, but it is observable, and people usually agree over the relative degree of complexity of any two given exhibits. –  tdammers Jun 21 '13 at 12:27
8  
I find it's generally good to use soap instead of rest when I need to take a shower, but am not particularly tired. (Sorry, I had to) –  KChaloux Jun 21 '13 at 12:50
9  
If SOAP is the answer, then someone asked the wrong question. –  btilly Jun 21 '13 at 16:57
3  
And the obligatory link: s stands for simple –  Florian Margaine Jul 16 '13 at 15:57

10 Answers 10

REST is built around the idea of doing CRUD operations on self-contained objects, or in a worst case, on a tightly coupled object hierarchy.

SOAP is less structured than this, and is therefore more suitable for transactions which have a more fluid structure. SOAP requests and responses have a defined structure, insofar as they have to conform to their WSDL, but that leaves a lot of room for optional elements, repeating elements, complex elements, and so forth.

share|improve this answer
    
there's no reason you can't send a SOAP packet (or other XML data structure) as part of your REST payload. No-one would do this as when using REST they're trying to get away from that SOAPy bloat. –  gbjbaanb Jun 21 '13 at 11:44
    
Sure, SOAP is bloaty, but not every transaction needs to be optimized for size. Sometimes flexibility trumps size, and it's not like sending a bloated payload in a REST wrapper is going to make the bloat any better. –  Joel Brown Jun 21 '13 at 11:50
3  
Out of all the excuses I can think of for using SOAP instead of REST, flexibility is certainly the farthest. REST is mostly exchanging documents, and it has almost nothing to do with self-contained or tightly coupled objects. The whole premise of WS-* is the more structured/less flexible aspect of SOAP. The fact that REST people are reluctant even to have a WSDL or an equivalent alternative clearly shows that. –  Muhammad Alkarouri Jul 16 '13 at 13:38
2  
You seem to confuse SOAP with REST, and REST with SOAP. –  Florian Margaine Jul 16 '13 at 15:48
1  
Don't forget that REST also includes the HATEOAS concept, which allows for mucgh more than atomic CRUD ops. It's a browsable web interface for computers, where you get/post forms. –  Macke Jul 16 '13 at 16:27

I'll start out with this: I much prefer REST to SOAP. REST has some great advantages, if done right, like distributability, cacheability of responses, clear defined semantics, the ability to be consumed directly in a browser, and so on. However, I like arguing against myself, so here's why you should use SOAP in your next project. A lot of these points come from REST In Practice which everyone should have on his/her desk when starting a REST-y project.

SOAP is everywhere

In the '00s, SOAP replaced a ton of un-interoperable technologies like CORBA, DCOM, RMI, to name a few. If there's a legacy system that you need to integrate with of that vintage, chances are it speaks SOAP, and will happily consume your WSDL. Every language imaginable has a tool that will parse WSDL into domain objects, and loads of developers know how to use it. That can't necessarily be said for REST. You could also go through the pain of interacting with a REST service through an HTTP client library directly (like Apache's HTTP Components). Tool support for REST is getting better: the latest JAX-RS 2.0 has a standard client that's pretty nice to use.

The S in SOAP stands for Simple

Here's the specification for SOAP 1.1. It's short, and outlines quite clearly what a SOAP message looks like. A lot of the spec is dedicated to IMO esoteric cases (never in 10 years have I ever used a partially-transmitted array, e.g.), but the meat of it is: Envelope, Header, Body. I'll concede that the Header and Envelope are redundant when the SOAP message is sent over HTTP, but SOAP can be sent over any medium (as another answer mentions), so it's a necessary evil. You can easily eyeball a SOAP message, and you don't need fancy software to write one either.

WS-* extensions add functionality

There's no in-built transaction support in REST-ful web services. It's possible to make a transactional REST service, but the semantics of your transactional system may be different from the semantics of my transactional system. SOAP has extensions like WS-Transactions that define clear workflows and mechanisms for transactional consistency. Likewise, other extensions like WS-Addressing and WS-Security describe message routing and message authentication/encryption. To do message authentication in REST, you either have to use client-side SSL, or roll your own.

SOAP doesn't require you to map domain operations onto CRUD

REST is not all about CRUD, but to perform non-CRUD operations, you have to map them onto resources. That's not necessarily a bad thing™, but it can cause your designers some headaches. Mapping a verb-operation like "check out a book" to one of the HTTP verbs could be a PATCH request to set an isCheckedOut flag on the book; it could be creating a new /checkout resource, or any number of other things. With a SOAPy web service, and auto-generated code from WSDL, you might simply do service.checkOut(book, patron). The intent is very clear.

SOAP's Fault mechanism encourages richer fault handling

OK, so it's not perfect, and most SOAP web services don't do it right, but that's not SOAP's fault. SOAP has built-in support for exceptions (faults), that are actual objects. They can contain great detail about what went wrong, and how you might fix it. REST's use of HTTP status codes is incredibly handy in this regard, because it encourages the developer to think about whether they should send back a 400, 403, 500, etc. and these codes have standard meanings. However, there's no standard for the message body, and there's no REST mechanism to enforce my-crappy-REST-service from sending back 200 OK responses with error bodies. It's just as easy for a REST service to produce unhelpful responses as it is for a SOAP service.

My experience

Maybe these aren't great reasons to use SOAP over REST in your next project, but I kind of wanted to try to convince myself.

I'm on a project at the moment that exposes a REST API, and consumes a SOAP API, so I'm in the best/worst of both worlds. I hate the SOAP stuff, but that's mostly because the back-end system that I'm working with leaves room for improvement. JAX-RS is a really nice server-side REST API, and it's nearly painless. Because of REST, and because we're being really strict about sticking to the REST constraints, we're making great use of HTTP caching in our infrastructure which will hopefully improve our user experience. We're not, however, doing a full-on HATEOAS service because our application simply doesn't require it. Our service is also primarily CRUD by its nature, so we haven't needed to make hard decisions about how to noun a verb.

In short, I guess SOAP isn't always a bad choice, but there's not a lot going for it unless you have a big SOAP infrastructure already.

share|improve this answer
2  
The S stands for Simple... –  Mason Wheeler Jul 16 '13 at 19:03
1  
Nothing about SOAP justifies the "Simple" moniker in the acronym. It is the most complex and obscure set of standards I have ever come across. However the tools available for SOAP are superb and you very rarely have to dig into the more secure aspects of the standard other than ticking a few boxes on a GUI. –  James Anderson Jul 18 '13 at 3:34
    
Agree. That's really a choice between pestilence and cholera. The pestilence is more widely supported (altough often broken) while the colera is more performant, but a little CRUDe on it's own. –  JensG Oct 7 '13 at 18:30

REST may look like CRUD, but in a Resource Oriented Architecture you can handle complex cases, though it may require some thinking.

For example if you want to charge a credit card, that may seem like a verb and thus wouldn't fit with CRUD, but there's no reason you can't have a Purchase resource. Then for a Purchase POST the service can actually charge the credit card behind the scenes.

share|improve this answer

From my understanding of REST, the implicit assumption is that all operations are CRUD operations.

Certainly not. You might be referring to an experience of one particular REST web service toolkit, but in general there is no restriction like that. REST is about exchanging documents, representations of state.

In fact, REST is so flexible you can describe your whole complex logic in a document, POST it to a /transactions URL, and use the returned /transactions/<id> to monitor the execution and grab the results. Whether such a shotgun application of REST is useful is another matter, and is dependent on the design of your application.

The SOAP/WSDL combination can be used when a rigid web interface contract is needed, a case that can be justified in some business scenarios. SOAP can be used with REST, but the SOAP/REST combination has not found its supporters, probably because it adds nothing of value to common REST architectures. I personally use SOAP, when I do, only for compatibility/legacy reasons. Or as part of the whole WS-* gamut when I was doing grid computing.

share|improve this answer

In addition to the great responses already here, another reason might be with who you are communicating with or what language you are developing in.

Some applications only have SOAP or REST interfaces. In other cases programming languages favor (by design or just practice) one protocol over the other.

For example. Ruby on Rails has excellent support for REST and if you need help a lot of resources. On the other hand, there are modules for doing SOAP in Rails, but they are not as well supported and you may have a lot more difficulty with that. Additionally the culture of Rails is to use REST and if you app does not support that you may not get Rails developers to use it or they will complain loudly about it.

On the other hand Microsoft has been a big supporter of SOAP and while I am not a C# or .NET programmer, it is my understanding that the support for SOAP there is very good. The same is somewhat true for Java, there seems to be better support for SOAP than for for REST there.

All this said, none of the examples above are impossible with one or the other, just that the culture of the programmers that use the language or the language itself tends to favor one or the other. You should take that into consideration when making your decision.

share|improve this answer

Soap makes more sense than rest when you know that you will stick with .net, and that your consumers will stick with .NET.

I say this, because with SOAP and visual studio integration, making the connection is a breeze.
Step outside of the .NET arena, and connecting to a rest service is a simple matter for any other language.

If you have to use .NET as a provider, and want to provide a rest like interface for your consumers, go with ASP.NET MVC, otherwise, go with WebAPI. (MVC allows for complex behaviors similar to SOAP, just make sure to document your inputs and outputs clearly)

share|improve this answer

When you only plan to interact with the Microsoft stack and large-scale bandwidth consumption is not a issue, SOAP is better.

Otherwise, offering a SOAP-only API to non-Microsofters, is generally considered rude, and I figure there must be some dictatorial state, somewhere, where it earns you a death sentence.

share|improve this answer
 > When does SOAP make more sense than REST?

With soap you have further interoperability standards WS-* that cover among others XML_Signature and XML_Encryption

In theory SOAP is not limmited to http(s) it can also be used via ftp, email,.... However i have never seen SOAP with non http(s).

If can choose between soap and rest i will always prefer rest.

share|improve this answer

SOAP gives you a well defined contract (WSDL) that is easily accessible to your clients. With the right technology, it makes it very easy to generate native APIs for your service.

This contract is also useful for clients to create fake implementations of the service for testing purposes.

share|improve this answer

From what I remember reading in a book.

1) SOAP imposes a structure

2) Using Soap is more secure

3) It can handle complex structures e.g. pass objects.

I think REST would be a better solution if you have small applications. Android has been using Rest and not soap, I guess because it is more lightweight.

share|improve this answer

Not the answer you're looking for? Browse other questions tagged or ask your own question.