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.