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.
asked Jun 21, 2013 at 10:11
-
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.– tdammersCommented Jun 21, 2013 at 12:27
-
9I 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)– KChalouxCommented Jun 21, 2013 at 12:50
-
10If SOAP is the answer, then someone asked the wrong question.– btillyCommented Jun 21, 2013 at 16:57
-
3And the obligatory link: s stands for simple– Florian MargaineCommented Jul 16, 2013 at 15:57
-
3SOAP makes more sense then REST when your boss says "Use SOAP or you're fired".– user53141Commented Jul 16, 2013 at 19:00
|
Show 6 more comments
10 Answers
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.
-
2
-
2Nothing 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. Commented Jul 18, 2013 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.– JensGCommented Oct 7, 2013 at 18:30
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.
answered Jun 21, 2013 at 10:50
-
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.– gbjbaanbCommented Jun 21, 2013 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. Commented Jun 21, 2013 at 11:50
-
3Out 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. Commented Jul 16, 2013 at 13:38
-
2You seem to confuse SOAP with REST, and REST with SOAP. Commented Jul 16, 2013 at 15:48
-
2Don'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.– MackeCommented Jul 16, 2013 at 16:27
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.
-
Agree 100%. The website we are all using now is a wonderfully usable resource oriented hypertext API between human, browser and machine via secure HTTP and the HTML media-type. You'd never describe the WWW as just CRUD. Building a REST API is building a website for machines to navigate and drive. Commented Jul 11, 2019 at 10:44
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.
answered Jul 16, 2013 at 14:46
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)
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.
> 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.
-
REST isn't limited to HTTP either. REST does not restrict communication to a particular protocol, but it does constrain the interface between components, and hence the scope of interaction and implementation assumptions that might otherwise be made between components. For example, the Web's primary transfer protocol is HTTP, but the architecture also includes seamless access to resources that originate on pre-existing network servers, including FTP [107], Gopher [7], and WAIS [36]. ref: ics.uci.edu/~fielding/pubs/dissertation/rest_arch_style.htm– nmtokenCommented Jun 23, 2015 at 12:46
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.
-
1) SOAP imposes a structure - I'd argue that REST has more structure since the call itself will not work without sufficient data. 2) Using Soap is more secure You can make REST very secure, all depends on how you implement it. 3) It can handle complex structures e.g. pass objects. Rest can do this as well, maybe not as nicely as SOAP calls, but again, not sure you can count this against REST. Commented Jun 18, 2015 at 19:06