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.
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.
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.
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.
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.
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.
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.
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.
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)
> When does SOAP make more sense than REST?
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.
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.