Back in the late 90s, when standards were proprietary and communication protocols complicated, two data formats appeared on the horizon. The first was the extensible markup language, born as an extension of an existing markup language standard (XML), and designed (by an open committee) with the purpose of storing and defining documents and data through the optional use of a schema. The other, JavaScript Object Notation (JSON), born out of a programming language, was almost the exact opposite – a serialization format with requirements so simple they fit on the back of a business card. XML exploded in application development and communication platforms in the 2000s due in large part to the sheer demand for a human readable, vendor-neutral data format that was easy to read, write and share. As applications and platforms evolved and efficiency grew in priority, APIs evolved to become leaner, and JSON overtook XML as the preferred data interchange format among developers across many technology stacks.
What started as a simple data structure native to the web programming language everyone wanted to slate to the history bins, has gone from relative obscurity to become the de facto data format used for quite literally everything in software development these days. To be fair, the rise of JSON came after developers collectively hit a wall with XML, which by the late 2000s had become the de facto standard used to develop the industry languages businesses use to communicate with each other. Even today, nearly all of these standards are still used and actively maintained despite the proliferation of JSON into the current year.
The seismic shift that started a needless debate
JSON, a data interchange format native to Javascript, is easier to deal with than the XML in the AJAX applications found in web clients. With the creation of server-side Javascript (a la Node), a seismic shift in web development took place. Web 2.0 suddenly got efficient – REST replaced web services for APIs, and JSON became the data structure standard in web apps. Web development, no longer was hindered by parsing data structures, which preceded an explosion in productivity and innovation that took Javascript, once considered a ‘dead’ language, to a first-class citizen on both client and server platforms.
While JSON as a data interchange format is great, things get more complicated as developers and vendors alike continue their efforts to extend JSON past its intended scope. With the modernization of agile software development lifecycles, software vendors update and release new products at an increasing rate. These faster release cycles often come at a cost that typically manifests itself in obsolete documentation or, worse, breaking changes for all downstream customers and other dependent products. Unconstrained by any binding data contract, it’s has become like the Wild West for software vendors who increasingly play “fast and loose” with their data structures, often at the cost of the productivity of their downstream customers who have now have to interpret what changed and what they need to do to support the change. To manage this, developers and vendors alike channel their efforts into bastardizing JSON beyond the scope of its original intent with schemas, namespaces, and versioning, all of which are optional at best, arbitrary and unenforceable at worst.
XML and JSON can actually play nice together
The truth is, XML and JSON are two data formats that complement each other, and developers would benefit from treating them as such. There are good reasons for using either format. JSON excels at data interchange but not data modeling, while XML is built to define data while requiring more work on the front end for integration. As XML tools increasingly add JSON support, developers should consider employing both formats in their solutions, with XML for data definitions and JSON for data interchange.
