Why JSON Triumphed Over SOAP

In recent years, JSON has prevailed as the leading protocol of choice for web-based APIs. However, this wasn't always so. Cloud computing developer Keith Ballinger explains that in 2000, SOAP & XML protocols for distributed computing were the rage, gaining much popularity endorsed by Microsoft and IBM. By 2004, clients implementing SOAP in all standard languages (Java, C/C++, .NET, Perl, PHP) were commonplace. 

At the time, Microsoft's Windows Communication Foundation was creating SOAP-based web services as part of WSDL. Large initiatives for security, messaging, and entire computing infrastructures aimed to replace DCOM and MSMQ.

Then, JSON emerged and began to replace XML as a serialization technology. As developers wanted to provide data to mobile clients themselves without the baggage, JSON was appealing as it provided a simple method for returning serialized formatted responses over HTTP. 

But what makes JSON better? To understand that one only needs only to look at the differences in code.

Take a situation in which we need to retrieve user information from a database. A SOAP call over POST HTTP to process this request is relatively long over 10 lines. The return is similarly just as dense, including superfluous data clouding the requested information in the middle of the response. 

Taking the same scenario, JSON, using a RESTful orientation over HTTP could call and retrieve the same information all in about 4 lines. It's quickly apparent that SOAP, in comparison to JSON, is bulky and hard on the eyes.

What JSON lacks is it's limited utility. No security is required in individual responses & returns, and it can't work without an HTTP transport, whereas SOAP can. According to Ballinger, simplicity nevertheless triumphs. 

Ballinger notes that large organizations such as Microsoft and IBM can't force the market to adopt technologies that are bulky. JSON is the simplest route, appealing to an increasing percentage of modern web developers. 

Be sure to read the next Protocol article: Why a Multiprotocol Approach will be Used for Industrial IOT

Original Article

Simplicity and Utility, or, Why SOAP Lost




Misleading headline. It's either:




You can't compare a protocol with a data format.



Don't know how old the frame of reference/perception about Microsoft/WCF but both XML and JSON data formats have been supported for some time now - don't know how long ago however (personally, around early-mid 2012, if memory serves).


Not only what Davehodg pointed out, but also the fact that JSON does not need an HTTP transport.

It is only a data specification. It can be used any place a "document" is used. I have written whole JSON blocks into text fields in relational databases to store information not explicitly defined in my schema. I used to do this in XML, but JSON works just as well. 

I also use JSON across a general purpose TCP connection.


JSON is also native in javascript: no parsing needed