63

Last I encountered a SOAP based service was during my internship in a financial firm in 2013. That was the time when I started my career in IT. I remember having some study material about SOAP in one of my engineering course. Outside of that, I haven't used SOAP much during my career.

I am asking this since the question of "Difference between SOAP and REST" came in one of my recent interviews. From what I know (and what I found on Google) SOAP is a protocol with tight coupling between client and server for information interchange which is closely related to business logic. Whereas REST is more flexible stateless architecture for data transfer.

Can someone please correct me if I am wrong about this difference between SOAP and REST? Also, what is the present-day significance of SOAP? Are people still developing new SOAP-based APIs, or it's mostly a legacy now?

Abhas Tandon
  • 723
  • 1
  • 5
  • 8
  • 3
    Possible duplicate of [What are the deciding factors in choosing to expose a web service as a SOAP or REST service?](http://softwareengineering.stackexchange.com/questions/111932/what-are-the-deciding-factors-in-choosing-to-expose-a-web-service-as-a-soap-or-r) – gnat Nov 22 '16 at 06:16
  • 7
    Did you ever actually see a REST service? All I see are "web services that finally learned what HTTP verbs mean". Why are we suddenly calling HTTP REST? – Luaan Nov 22 '16 at 14:42
  • 8
    @Luaan: There's nothing sudden about it; people have been abusing the term "REST" for years. – Lightness Races in Orbit Nov 22 '16 at 18:44
  • 1
    @Luaan There are brilliant REST examples (Twitch's Kraken API comes to mind) but LightnessRacesinOrbit is correct, they are few and far between. If a job posting said they want REST I'd assume they mean HTTP enabled web services and accept it. RIP purists. – corsiKa Nov 22 '16 at 20:30
  • 1
    In the present day, SOAP is a thing that your mouth should be washed out with if you so much as suggest that it's a good idea to use XML as a communications protocol. – Mason Wheeler Nov 23 '16 at 03:24
  • @corsiKa Well, I'm no purist. The main issue I see everywhere around me is that everyone expects to get the benefits of REST (e.g. weak coupling) without actually using the methods that provide those benefits (e.g. hyperlinks). There are some who do REST that's actually REST, but for the rest, the only benefit to "JSON REST Web Service" is that their client-side javascript is simpler - but they still pretend they get all the other benefits! But since there's little reflection, most people don't even notice - it "feels" more productive anyway, just because everyone says so :D – Luaan Nov 23 '16 at 09:48
  • Well I can tell from experience they're really fast to develop and have found they lead to much cleaner code. It's also a lot nicer for exchanging front ends. – corsiKa Nov 23 '16 at 16:19
  • I think part of why we use the term "REST", is because we don't have to worry about 100 different overcomplexed and often unnecessary things so we have an actual time to "rest" – Felype Sep 05 '17 at 18:21

3 Answers3

71

REST is indeed an architectural style. SOAP is a data protocol. The distinction is important; you cannot compare them directly.

The primary purpose of REST is to represent resources on the Internet, and to provide mechanisms for discovering them. In contrast, SOAP is used for communicating structured data between computers, and that's all it really does.

Note that you don't actually need REST to create a client/server relationship between two computers on the Internet. All you need is a mechanism that transfers JSON or XML, and you don't even need that if you're willing to be incompatible with everyone else.

Nevertheless, SOAP has fallen out of favor for new, public-facing API's, though it is still commonly used for B2B applications because you can define a "data contract" with it. JSON web services have the virtue of being rather lightweight and flexible, and since Javascript recognizes JSON natively, it's a natural choice for browsers.

But none of that has much to do with REST, really.

Further Reading
Is REST better than SOAP? (good article, even though it incorrectly calls REST a protocol).
The Richardson Maturity Model

Robert Harvey
  • 198,589
  • 55
  • 464
  • 673
  • 3
    I'd say the killer feature of JSON web services is exactly the fact that browsers have poor support for XML and SOAP, while they have (nearly) native support for JSON. SOAP has plenty going for it, but if you can't make AJAX requests against a SOAP service, it's dead. Javascript/JSON became the lowest common denominator of the internet, so you'd need a huge benefit not to use it, and SOAP isn't *that* much better. – Luaan Nov 22 '16 at 14:45
  • 4
    @Luaan I wouldn't say browsers have poor support for XML. In fact, it's hard to get any better than doing an *XML*HttpRequest and accessing an attribute which has a parsed DOM. It's just that if what one wants is a typical data structure, and not a document, JSON is simply more suitable, whether you're in the browser or in any other environment. – André Paramés Nov 22 '16 at 17:45
  • 4
    *All you need is a mechanism that transfers JSON or XML, and you don't even need that if you're willing to be incompatible with everyone else.* -1 : If you want to connect a client and server you just need an arbitrary protocol which both sides understands it's has nothing to do about using xml, JSON or being compatible with everyone else. Even using json or xml doesn't guarantee that your compatible with everyone or even someone. Json and xml are just data formats nothing more. – Paul Wasilewski Nov 22 '16 at 19:05
  • 6
    @PaulWasilewski: Yes, *that's what I said.* Don't get hung up on words. There's a reason everyone uses JSON; *it's a standard.* Using it guarantees that you're using something that is recognizable to others. – Robert Harvey Nov 22 '16 at 19:07
  • 3
    @RobertHarvey, no it's not what you wrote maybe you meant it. JSON is standard so what? CSV, Protcol Buffers, BSON is standardized as well as many others. So the reason why everybody is using JSON is manifold. And there are even some who are using JSON because everybody is using JSON ;) – Paul Wasilewski Nov 22 '16 at 22:39
  • Richardson here has no problems comparing REST and SOAP http://martinfowler.com/articles/richardsonMaturityModel.html – Esben Skov Pedersen Nov 23 '16 at 07:07
  • @EsbenSkovPedersen, I don't see where he is comparing REST and SOAP? He compare REST style over RPC style. And even Richardson can failable. – Paul Wasilewski Nov 23 '16 at 08:14
  • You can also define a data contract for [JSON](http://json-schema.org/) and for the [RESTful API](http://raml.org/). It's just that the [Chevy Chase pratfall-esque history of SOAP/WSDL](http://harmful.cat-v.org/software/xml/soap/simple) led to machine-readable contracts falling out of vogue. – JimmyJames Nov 23 '16 at 19:04
  • @JimmyJames: Is that the real problem with JSON-SCHEMA adoption, or is it that JSON-SCHEMA is not backed by a large company like SOAP was? – Robert Harvey Nov 23 '16 at 19:08
  • 1
    @RobertHarvey Hard to say really. It's the network effect that makes something gain acceptance as a standard more than it's technical merits. What triggers that can be a dominant player like the guvment or MS and IBM back in the day. I think that there's an aspect of not wanting to use standards based on experience with SOAP/WSDL because I've read enough people saying so to think it's a common sentiment. The reality is that every service needs a contract. The question is how that contract is communicated. Maybe a player like Google could cause adoption of a standard. – JimmyJames Nov 23 '16 at 19:47
  • @JimmyJames: Well, one thing that might have made SOAP so popular in its heyday was that it was very easy to stand up an interface contract. There were actually code generators that would write the C# code for you; all you had to do was plug values into the resulting objects and call a Send method. It might have been Chevy Chase with a saxophone under the hood, but on the surface it was ridiculously trivial to use (The dog's breakfast that was WCF notwithstanding). – Robert Harvey Nov 25 '16 at 17:52
  • @RobertHarvey I can believe that it was easy with MS tools on both sides but it was severely lacking in terms of interoperabililty. There was a need to create a [standard on top of the standard](https://en.wikipedia.org/wiki/Web_Services_Interoperability) just to stop the chaos. – JimmyJames Nov 28 '16 at 14:39
  • Yes, the worlds first attempt at a platform and language independent interface description language didn't start well. It's mostly because it was back in the day when everyone thought vendor lock in was a good idea so they "extended" SOAP (eXtensible!) So yeah, they wrote WSI and then SOAP worked. Once the standard was standard it worked really well..... IF you took the time to learn XML, XSD, WSDL, WSI, etc, etc. And they STILL "added bits" (WCF attributes! woo!) – RoboJ1M Apr 26 '19 at 16:26
  • Tell you what though, 10 years ago, once I'd taught everybody contract first, XSD and server and client generation and we version controlled the spec and got used to designing data structures in XMLSpy rather than, ahem, "rapid" development with code-first? They'll defend SOAP with their life blood now, NOBODY wants to go back to "flexible" or "evolutionary" design... X-S – RoboJ1M Apr 26 '19 at 16:31
  • Of course the *fantastic* news is Swagger/OAS/JSON Schema exists now. So you can define a contract for your WebAPIs!!! – RoboJ1M Apr 26 '19 at 16:33
35

REST is much more limited than SOAP, which is its strength and the reason for its popularity.

In SOAP, the set of operations allowed and the set of data types allowed is essentially limitless. SOAP is a remote procedure protocol, which you use to expose local API's across the network without losing any fidelity. This made SOAP popular in enterprise environments where complex transactional systems needed to interact across the network without losing any fidelity along the way. This richness in ability is also SOAP's downfall, because it makes SOAP API's so cumbersome to understand and use that it necessitated automated tooling in the form of WSDL and SOAP client libraries to make sense of things. More so, exposing the full richness of the underlying system is unattractive in public-facing API's, where you want to provide abstractions that let you evolve the underlying system without having to break or version your API.

REST+JSON gained popularity specifically because of its simplicity. It defines a limited set of operations with a limited set of data types, requiring the API designer to carefully design abstractions that fit inside this limited vocabulary and really think through the mapping of business domain to REST resources. A REST API is easy to understand and easy to use without any special tooling. For a public-facing API where your API users may have all levels of skill and knowledge this is exactly what you want, which is why all of the API's you see around the web have been transitioning to REST. SOAP is relegated to enterprise situations where there is still a desire and need to share complex API's between systems. However, with architectural trends towards independently versioned micro-services developed by separate teams even that domain is losing ground.

Essentially, what people have realized is that the set of constraints that you must apply to your API design to make the API simple and abstract enough that it is maintainable and easy to use is exactly the set of constraints that REST introduces, which effectively neutralizes SOAP's benefits leaving you with only its downsides. You could build a simplified API with SOAP, but it would never be as easy to use as REST, so in practice everybody just chooses REST.

Joeri Sebrechts
  • 12,922
  • 3
  • 29
  • 39
  • 5
    The good old static versus dynamic typing debate, yay :D Neat and hard vs. hacky and simple, the war that never ends. – Luaan Nov 22 '16 at 14:46
  • @Luaan ...and dynamic *always* wins for data interchange. https://www.youtube.com/watch?v=ROor6_NGIWU – Jared Smith Nov 22 '16 at 19:02
  • 6
    @JaredSmith I disagree strongly. Contracts are supposed to be followed so both endpoints map the data correctly, if you can do that through metadata publishing instead of error prone documentation pages why wouldn't you? – Drakarah Nov 22 '16 at 19:57
  • @drake7707 because systems have different emergent properties than programs. Watch the Rich Hickey video I linked. – Jared Smith Nov 22 '16 at 19:59
  • 1
    REST is an architectural style SOAP is just a protocol. REST has no limitations it has architectural constraints. – Paul Wasilewski Nov 22 '16 at 22:52
  • 1
    Practical REST is is a protocol; The thesis and religion are 'architectural style'. This answer correctly compares practical rest to practical soap. – bmargulies Nov 22 '16 at 22:59
  • 1
    Your answer already shown that you don't understand REST and you comment underlines that. – Paul Wasilewski Nov 23 '16 at 00:34
  • REST APIs are also versioned, and they also break. So those supposed benefits are out the window. I've never used SOAP, but I can say with certainty that I despise REST (the protocol, not the architectural style, which has some fine ideas). – gardenhead Nov 23 '16 at 01:44
  • @gardenhead: Not all that surprising, since REST the Protocol™ doesn't actually exist. Whatever you've discovered was probably invented by the same guys who think DDD is a coding technique. – Robert Harvey Nov 23 '16 at 19:23
  • 1
    I'm with @PaulWasilewski. After the first sentence I stopped reading. The truly alarming thing is the number of up votes. Perhaps this sort of thing helps explain a web site where the use of POST, GET, query parameters, request object content, and so on seemed to be determined by rolling dice. – radarbob Nov 25 '16 at 04:18
  • @radarbob: In what way is it wrong to say that a RESTful style is much more restrictive than SOAP on what set of verbs/operations are allowed? The sites that roll the dice for their verbs are not REST in my opinion. – Joeri Sebrechts Nov 25 '16 at 08:14
7

You can not compare REST and SOAP. REST is a architectural style whereas SOAP is a protocol.

Unfortunately, REST became colloquial spoken an synonym for RESTful HTTP service, that means a realization of REST styled architecture with HTTP as (application) protocol.

REST is based on following principles (constraints and elements) (in brackets the realization in RESTful HTTP) [1].

  • Stateless (HTTP is a stateless protocol)
  • Resource (identified by URIs)
  • Uniform Interface (HTTP Methods)
  • Representation (MIME-TYPE)
  • HATEOS (Hyperlinks)
  • Cache (HTTP Cache)

On the other side many people mean by saying SOAP a web service based on WSDL and SOAP which are part of the W3C web service architecture [2].

  • SOAP is used as protocol to exchange information (basically method name, parameters, return values, data types, ...).
  • WSDL a interface definition language to describe the web service.

What is the present-day significance of SOAP*?

SOAP is a W3C standard and it's used as information exchange format in W3C web services. Those web services were - especially during the hype of SOAs (service-orientated archtitectures) around 2008 (+- 3 years) - and (unfortunately) are still implemented mostly in enterprise applications.

This has several reasons. Back then RESTful HTTP was not well-known, and it was misunderstood. Unfortunately, it's still misunderstood take a look at the other answers

„[...]REST is much more limited than SOAP[...].“

„The primary purpose of REST is to represent resources on the Internet[...].“

Additionally, SOAP (and WSDL) are a part of W3C web service protocol stack which provides even more standards for implementing a Web Service.

Are people still developing new SOAP-based APIs, or it's mostly a legacy now?

So yes, there are still and there will be also in future systems out there which are using SOAP (at least in enterprise systems, mostly behind the doors). But the majority is trying to do some kind of "REST" nowadays.

Can someone please correct me if I am wrong about this difference between SOAP and REST?

Saying REST is more flexible stateless architecture for data transfer is not a good explanation. Simply spoken REST is an architecture style with specific constraints and elements. Whereas SOAP is an information exchange protocol.

Like I already wrote you can not compare them. But you can compare a RESTful HTTP Web Service with a SOAP/WSDL Web Service.

Community
  • 1
Paul Wasilewski
  • 296
  • 1
  • 5
  • 1
    "But you can compare a RESTful HTTP Web Service with a SOAP/WSDL Web Service." But that's what the OP is asking. Has anybody answered that yet? – RoboJ1M Apr 26 '19 at 16:18