9

I'm really confused everytime I come around this question, what characteristics would help one choosing SOAP over REST or the other way around?

I mean, besides the fact that REST has a compact format compared to SOAP, and the other "minor" or "technical" differences, what are the "obvious" differences that make one of them more suitable for a project and not the other?

Just for the record, I have read all of the other questions (1|2|3|4) regarding this matter on Stack Overflow, and not one of them answered my question.

Community
  • 1
  • 1
Shotgun
  • 668
  • 2
  • 10
  • 24

3 Answers3

12

The difference between REST and SOAP is fundamental, yet they're not that dissimilar. Ultimately, you still need to transfer exactly the same information in order to perform a particular abstract operation. It's entirely easy to make REST rather low-performing by choosing poorly what information to return, and SOAP with MTOM can transfer large binary chunks efficiently. There's even the possibility to use non-XML encodings and connected transports (e.g., XMPP) with SOAP that can make it more efficient than REST.

So don't worry about that!

A much more relevant thing to think about is that SOAP continues to have significantly more advanced tooling support in some languages, and that other languages strongly prefer REST. For example, if you want a Java client for your service, you'll be able to get going with SOAP in minutes: just put the WSDL location through a tooling engine and you've got yourself a basic client. On the other hand, if you're working with a Javascript client then you'll absolutely prefer to deal with the REST interface; Javascript works great with REST.

A key thing to note here is that you can have your service support both SOAP and REST at once (you might need to put them on different endpoints, but that's not very onerous). I do this with a service I support (using Java and Apache CXF) and the overhead of doing both is minimal: the key is that I need a clean abstract interface behind the scenes that both the SOAP and REST interfaces use.

Donal Fellows
  • 133,037
  • 18
  • 149
  • 215
  • 4
    Nice answer. I think the key point is that SOAP is structured -- you have the WSDL, you know exactly what the data will look like -- while REST is generally free-form (although it [doesn't have to be](https://developers.helloreverb.com/swagger/)). – Dagg Nabbit Nov 21 '13 at 05:56
  • 4
    @Dagg There seems to be plenty of debate between different approaches to REST; some want lots of flexibility, and others want predictability. I suppose it really depends on your attitude to third-party clients: “they must adapt to me” vs “I need to support them”. SOAP/WSDL tends to be a bit more towards the “I support them”. I prefer to publish a contract for my services; they tend to be semantically-complex enough that clients _need_ to understand what they're up to… – Donal Fellows Nov 21 '13 at 09:01
  • 1
    There's a flipside to that, though. If you're using tooling to generate the SOAP server, and tooling to generate the client, everything's fine... usually. But sometimes the server generates a ridiculously complex scheme, and for whatever reason your client of choice can't handle it (this has happened to me more than once). At this point, you may need to do things by hand, and it's way more trouble than figuring out what to do with a RESTful service with simple experimentation. I think that's why things tend to be moving more towards REST. – Dagg Nabbit Nov 21 '13 at 09:19
  • 2
    I also think it's partly cultural. The strictly-defined nature of SOAP services is more appropriate for strongly-typed languages, I think, where you'd want to set up classes with the appropriate properties and whatnot to translate the response into. In weakly-typed languages, it's not as much of a problem to say "here's an object and it has some properties," you don't need to know exactly what it looks like. – Dagg Nabbit Nov 21 '13 at 09:21
  • But, yeah, I prefer to publish a contract too. I use Swagger (linked above). This gives all the simplicity of REST, with metadata on the side to generate client code. One big plus is you can map resources (nouns) to "nicknames" (verbs) that are used by code generators as function names, so you end up with something like a SOAP-like layer on top, where you can deal with operations instead of resources... in fact it's fairly easy to generate the Swagger metadata from server code introspection, and end up having the client api look nearly identical, but with a proper RESTful layer in between. – Dagg Nabbit Nov 21 '13 at 09:27
  • If you have REST and RPC API then I'd conclude right off the bat your REST API is not REST at all. Is this a public API we could take a look at? – EralpB Jan 09 '17 at 11:34
3

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

JTech
  • 3,420
  • 7
  • 44
  • 51
2

SOAP is a form of RPC and REST is architecture style that can scale with the web.

REST concerns about the following (copied from RESTful Web Services)

  • Addressability
  • Statelessness
  • Representations
  • Links and Connectedness
  • The Uniform Interface

Two great books on REST and have some discussions on the topic that you are interested in.

Ming Chan
  • 1,938
  • 11
  • 21