Are JSON APIs Kicking XML’s Butt?
A decade ago, XML emerged as the primary data interchange format. At inception, it provided a breath of fresh air and a great improvement from its predecessor – Standardized Generalized Markup Language (SGML). It is credited for introducing file sharing across HTTP connections and enabling other Internet (including Microsoft Office) functions. However, in the recent years a bold transformation has been taking root.
In a nutshell, the more lightweight, bandwidth non-intensive, JavaScript Object Notation (JSON) has been slowly upstaging XML; not as a competing alternative but as a full-blown successor. To fully appreciate this fact, let’s consider statistics from Programmableweb: JSON held a market share of 51% (while XML had 49%) of new APIs added between March and April 2011. This has to be viewed from the perspective that XML has been in the market for twice as long as JSON.
Comparison between XML and JSON
A number of factors can be pointed as the drivers behind this trend, but the major one is the complexity associated with XML. JSON’s popularity is largely based on its simplicity and nonconformity to XML protocols.
JSON’s simplicity is exemplified in two forms; the rules of serializing data, and the interfaces of parsing data. Unlike XML, the latter’s parsing and serialization rules are fairly simple. JSON data is grouped as objects, featuring arrays, strings, Boolean or numbers. They do not have metadata or metadata structures, common in XML, that require processing instructions to have entity references.
Additionally, XML is mostly considered as unstructured, but in practice it adopts a more structured framework than JSON. This is due to the fact that it uses metadata standards that constrain identity, security, and application formats. On the other hand, JSON adopts very few standards apart from those imposed by toolkits and frameworks such as JQuery. In the long run this brews a challenge especially for infrastructure vendors who provide support services targeting application data – web application firewall, data scrubbing, IPS and advanced routing – to continue to deliver applications without recognizing JSON as an alternative.
Typical of any new technology, the lure of simplicity and availability of user-friendly features plays a great role in boosting the product/service market penetration. However, as they say the devil lies in the details, it’s imperative to not only dwell on the superficial aspects of a technology but also its technical aspects. Some of JSONs technical aspects are;
- JSON is not Java Script
- Character Set Support
- Schemas
- Performance
- Namespaces
It is important to point out that JSON is a language independent data format. However, the constructs of JSON arrays and objects adopt JavaScript semantics.
JSON purely relies on Unicode and hence non-Unicode encodings are incompatible. This is in contrast to XML in which ISO-8859-1, US-ASCII, Shift_JIS, and other character sets can be explicitly specified.
In reality there is no standardized schema language for JSON. However, the debate for needing a standardized schema language is mired by controversy partly because JSON is viewed to be too simple on its own.
From a general perspective, JSON is less ‘wordy’ than XML, resulting is less payload volumes and memory required.
Currently JSON has no standardized name-space specification. This is partly attributed to the fact that many JSON specifications do not require a name spacing function nor the complexities associated with federated name-spacing system.