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. 

Original Article

Simplicity and Utility, or, Why SOAP Lost

Bill Doerrfeld is an API specialist covering the API economy, specializing in evergreen content and evangelism for developer programs. He is the Editor in Chief for Nordic APIs, and formerly Directory Manager & Associate Editor at ProgrammableWeb. Drop him a line at bill@nordicapis.com. Connect to Bill on Twitter at @DoerrfeldBill, put him in a Google+ circle, or follow him on LinkedIn.

Comments

Comments(5)

davehodg

Misleading headline. It's either:

JSON vs. XML

or

REST vs. SOAP.

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

 

EdSF

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).

webatxcent

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.

jesuino

JSON is also native in javascript: no parsing needed