Understanding JSON and compare it to XML

In this day and age of continuous delivery and integration, the focus is continuously moving away from software interface and on to APIs. One of the prime objectives of DevOps is to achieve end to end automation of delivery. For this, the various kinds of softwares which are used in the process of delivery, need to exchange data. This is where APIs come in handy. Using APIs, there is no manual intervention needed, and all the data can be exchanged easily.

APIs, more specifically REST APIs, return data when queried. The earlier format of choice used to be XML, then it turned over to XAML but now the focus is on JSON due to its easiness. JSON is a way of structuring data that makes it easy for software to consume.

The JSON format has been used more and more across the internet, especially for Websites. REST Api can be found everywhere nowadays; Microsoft Azure, office 365, and almost every ‘big’ web site). JSON is very popular, and is by far the prefered method to get information back from a REST API endpoint, since it compact, light, and easy to work with.

What is JSON actually?

JSON is an open, text-based data exchange format for objects. It came from Java world where it stands for JavaScript Object Notation. One of the reasons that JSON has become more famous is that it is less verbose then XML. This means that in order to hold equivalent information, you will need less writing in JSON, then in XML. Also, another reason is that more and more focus is on to the Mobile Apps, where one usually runs a JavaScript based code and request data from a server. Since the data sent in JSON format is already an object and is light-weight, it fits right in and software developers don’t have to do much to process the data sent by server.

JSON format for Data

The charm of JSON is in its simplicity. A message formatted according to the JSON standard is composed of a single top-level object or array. The array elements and object values can be objects, arrays, strings, numbers, Boolean values (true and false), or null. That, in a nutshell, is the JSON standard! It’s really that simple. Virtually all modern programming languages support them in one form or another. It makes sense that a data format that is interchangeable with programming languages also be based on these structures.

So, when an object is used as data structure, the data will be like:


Object format for JSON
Object format for JSON

And, when it’s an array:

Array format for JSON

Again, an value can be anything. It can again be an object or array of objects, which can contain strings, numbers, boolean values.

Do note that, there is no date/time literal in JSON. The simple explanation (consoling or not) for the absence of a date/time literal is that JavaScript never had one either: The support for date and time values in JavaScript is entirely provided through the Date object. Most applications using JSON as a data format, therefore, generally tend to use either a string or a number to express date and time values.

See JSON as in examples

An object in JavaScript is called an Object literal. It start with the opening of a curly brace and ends with the closing curly brace. It is as simple as that. For example, this would be valid sample of an Object:

"Author": "Mohit Goyal"

In above example, we have very simple object with two properties: Site and Author. These two properties are separated by a comma.

Let’s expand our example by adding an object as an property type:

 "Site": "mohitgoyal.co",
 "Author": "Mohit Goyal",
 "Post": {
         "Category": "DevOps",
         "Tags": ["DevOps", "JSON"]

In above example, we added a property named Post, which is an Object. It has two properties named Category (which happens to be a string literal) and Tags (which happens to be a array).

We’ll now add a property to Post property which also happens to be Object, in below example:

 "Site": "mohitgoyal.co",
 "Author": "Mohit Goyal",
 "Post": {
    "Category": "DevOps",
    "Tags": ["DevOps", "JSON"],
    "Others": {
        "Words": "645",
        "Letters": "2400",
        "Stat": ["0", "1", "2"]

You can expand the rest to your imagination. We can have very complex data sent in JSON. It easily scales up/down.

Comparing JSON to XML

Both JSON and XML can be used to represent native, in-memory objects in a text-based, human-readable, data exchange format. Furthermore, the two data exchange formats are isomorphic—given text in one format, an equivalent one is conceivable in the other. Therefore, when deciding upon a data exchange format, it’s not a simple matter of choosing one over the other as a silver bullet, but rather what format has the characteristics that make it the best choice for a particular application. For example, XML has its roots in marking-up document text and tends to shine very well in that space (as is evident with XHTML). JSON, on the other hand, has its roots in programming language types and structures and therefore provides a more natural and readily available mapping to exchange structured data.

Below table is a crisp summary of differences:

Characteristic XML JSON
Data types Does not provide any notion of data types. One must rely on XML Schema for adding type information. Provides scalar data types and the ability to express structured data through arrays and objects.
Support for arrays Arrays have to be expressed by conventions, for example through the use of an outer placeholder element that models the arrays contents as inner elements. Typically, the outer element uses the plural form of the name used for inner elements. Native array support.
Support for objects Objects have to be expressed by conventions, often through a mixed use of attributes and elements. Native object support.
Null support Requires use of xsi:nil on elements in an XML instance document plus an import of the corresponding namespace. Natively recognizes the null value.
Comments Native support and usually available through APIs. Not supported.
Namespaces Supports namespaces, which eliminates the risk of name collisions when combining documents. Namespaces also allow existing XML-based standards to be safely extended. No concept of namespaces. Naming collisions are usually avoided by nesting objects or using a prefix in an object member name (the former is preferred in practice).
Formatting decisions Complex. Requires a greater effort to decide how to map application types to XML elements and attributes. Can create heated debates whether an element-centric or attribute-centric approach is better. Simple. Provides a much more direct mapping for application data. The only exception may be the absence of date/time literal.
Size Documents tend to be lengthy in size, especially when an element-centric approach to formatting is used. Syntax is very terse and yields formatted text where most of the space is consumed (rightly so) by the represented data.
Parsing in JavaScript Requires an XML DOM implementation and additional application code to map text back into JavaScript objects. No additional application code required to parse text; can use JavaScript’s eval function.
Learning curve Generally tends to require use of several technologies in concert: XPath, XML Schema, XSLT, XML Namespaces, the DOM, and so on. Very simple technology stack that is already familiar to developers with a background in JavaScript or other dynamic programming languages.

That said, the allure of JSON lies in its simplicity to understand, adopt, and implement. JSON has virtually no learning curve for developers already familiar with JavaScript or other programming languages with similar support for a rich literal notation (like Python and Ruby).

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s