Fast and efficient are good qualities to strive for whether you are creating super-spies, or selecting a format for transferring data. Jason Bourne excelled at what he did largely because he was able to think quickly and react even more quickly. It was fun to watch him get out of situations using his wits that would have left most of us in the fetal position.  Less exciting, but more pertinent to those of us in the fast paced world of software development, is the need to move large amounts of data between two entities. It could be a RESTful API, it could be named pipes, or it could be just pushing data to a file, but at some point a big chuck of data needs to be moved as quickly and efficiently as possible.

The good news for developers in this situation is that without any biomedical augmentation they can use JSON, or “Javascript Object Notation”. Created by Douglas Crockford, it was designed to be a fast and efficient alternative to XML. It is human readable (text), and it is based on attribute-value pairs. This reduces the number of characters required to represent data. It supports arrays, and objects. While JSON is becoming popular in many environments, it was initially targeted for use in AJAX calls made in JavaScript on the client side of web traffic. This is the source of the “Javascript” in the name.

Since computers are much better at parsing very long strings that don’t look so pretty, most of the time JSON is sent as one big “run-on sentence”, but it is possible to format the data so it’s easily parsed by us slow sub-Jason folks. A sample might look as follows:

 

In the above example you can see the “attribute/value” pairs as well as the two main organizational constructs: arrays and objects. Objects are entities that do not have a specific value, but have child attribute/value pairs. Arrays are entities that have a name, and then series of elements. The elements are groups of attribute/value pairs. Generally the elements in an array have the same sets of attributes, but this isn’t enforced by JSON. Tools that process JSON into typed languages may be a bit pickier.

A more interesting example would be the data that represents a recipe.  

 

The above JSON sample contains the data for a collection of lunch recipes. There sample contains a mix of objects and arrays. The sample has a single attribute of title and then an array of “recipes”.  Each element of the “recipes” array is an object of type “recipe”. The use of plural names is common in JSON when naming a collection of like items. “Recipes” for a collection of “recipe” objects. “Recipes” is an array, but the individual elements of the array are objects of type “recipe”. The “recipe” objects contain a “name” attribute and then two arrays, one for ingredients, and one for the steps of the recipe. By being able to mix arrays and objects, JSON provides great flexibility in representing complex data structures without significant overhead or extra text that would add up if the data being represented was large.

An astute reader might notice that the array of ‘recipes” is made up of objects with a name, but the arrays of “ingredients” and “steps” are not made up of “ingredient” or “step” objects. It would be possible to have an ‘ingredient’ or ‘step’ object in the above sample, but with the goal of JSON being light and efficient, there is minimal value. Using the same argument the “recipe” object could have been omitted as well. In this case “recipe” was used to provide clarity for the example, but if the data to be represented by this JSON were large, there could be savings to not using it.

In addition to data size, when determining how to format data in JSON, consideration should be given to how the JSON data will be created and consumed. Javascript was the original targeted consumer of JSON. The characters and structures used in JSON are native to Javascript, and properly formatted JSON is valid Javascript code. With some big caveats that are beyond this blog, Javascript can natively consume JSON and convert it to objects that can be used. As JSON has become more and more ubiquitous, other languages have added support for creating and consuming JSON.  In most cases, regardless of language, when JSON is consumed, the data represented will be pushed into classes that are represented in the JSON. This can a dynamic process or the structure of the data can be known ahead of time.

Another question an astute reader might ask is: “if fast and efficient” are the goals, why not use a more structured, fixed format such as comma separated values where every field is known. Such an approach would work as long as there was agreement of the structure of the data. What JSON allows is flexibility and discovery. In cases where the data structure may not be fixed, JSON supports the required flexibility. On top of this, because JSON has become so ubiquitous, creating services and communication channels that use JSON satisfies a large number of potential users better than a custom data format.

JSON might not be as exciting as playing a high stakes cat and mouse game throughout Europe, but in terms of being fast and efficient JSON is the Jason of the data transfer world. In my next blog I’ll explore how TruePlanning data could be represented in JSON data.