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?

Improve this question
8
  • 3
    Possible duplicate of What are the deciding factors in choosing to expose a web service as a SOAP or REST service?
    – gnat
    Nov 22, 2016 at 6: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, 2016 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, 2016 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, 2016 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, 2016 at 3:24

3 Answers 3

Reset to default
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

Improve this answer
15
  • 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, 2016 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 XMLHttpRequest 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, 2016 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, 2016 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, 2016 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, 2016 at 22:39
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.

Improve this answer
11
  • 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, 2016 at 14:46
  • 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, 2016 at 19:57
  • 1
    REST is an architectural style SOAP is just a protocol. REST has no limitations it has architectural constraints.
    – Paul Wasilewski
    Nov 22, 2016 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, 2016 at 22:59
  • 1
    Your answer already shown that you don't understand REST and you comment underlines that.
    – Paul Wasilewski
    Nov 23, 2016 at 0:34
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.

Improve this answer
1
  • 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, 2019 at 16:18

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

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