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 I am a consultant that specializes in API economy research & content creation for developer-centric programs. I study Application Programming Interfaces (APIs) and related tech and develop content [eBooks, blogs, whitepapers, graphic design] paired with high-impact publishing strategies. I live and work in Seattle, and spend most of my time as Editor in Chief for Nordic APIs, a blog and knowledge center for API providers. For a time I was a Directory Manager & Associate Editor at ProgrammableWeb, and still add new APIs to the directory every now and then. Drop me a line at bill@doerrfeld.io. Let's connect on Twitter at @DoerrfeldBill, or follow me on LinkedIn.

Comments

Comments(6)

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