What is the present-day significance of SOAP

Question

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?

Answer 1

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

Answer 2

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.

Answer 3

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.