Chapter 10. Conclusion
From about 6,000 feet, we can see JSON flitting about in the world, carrying data in and out of systems. JSON is great at doing its job as a data interchange format, and we have seen that expressed in this book. However, if you look closely through your binoculars, you can see that JSON is simply staying put in some places.
Despite the phenomena of JSON staying put in some places, this book has mostly ignored the subject. The focus has been on interchanging data between two parties. Essentially, moving data.
JSON can be both a receptacle and a vehicle for data, and it is not bound to a single purpose. We saw that illustrated with the role of JSON in NoSQL. More and more, JSON is making its way into projects and endeavors as a very useful tool. To further illustrate, let’s take one last look at a role that JSON plays out in the world today: staying put in one place as a configuration file.
JSON as a Configuration File
In Chapter 9, we explored two server-side web technologies that support parsing JSON. As discussed in that chapter, JSON is widely supported by most server-side web languages (or frameworks). It has become popular to use JSON for storing configuration data due to wide support, ease of parsing on the server, and human readability.
A configuration or settings file is often used in software, so settings may be changed without having to recompile. There are several formats for configuration files, including INI and XML.
Let’s take a look at how we could store the same settings information in INI, XML, and JSON format (in Examples 10-1, 10-2, and 10-3, respectively).
Example 10-1. An example of a game settings file in INI format (settings.ini)
[general] playIntro=false mouseSensitivity=0.54 [display] complexTextures=true brightness=4.2 widgetsPerFrame=326 mode=windowed [sound] volume=1 effects=0.68
Example 10-2. An example of a game settings file in XML format (settings.xml)
<?xml version="1.0" encoding="UTF-8" ?> <settings> <general> <playIntro>false</playIntro> <mouseSensitivity>0.54</mouseSensitivity> </general> <display> <complexTextures>true</complexTextures> <brightness>4.2</brightness> <widgetsPerFrame>326</widgetsPerFrame> </display> <sound> <volume>1</volume> <effects>0.68</effects> </sound> </settings>
Example 10-3. An example of a game settings file in JSON format (settings.json)
{
"general": {
"playIntro": false,
"mouseSensitivity": 0.54
},
"display": {
"complexTextures": true,
"brightness": 4.2,
"widgetsPerFrame": 326,
"mode": "windowed"
},
"sound": {
"volume": 1,
"effects": 0.68
}
}
All three of these formats are human readable. If I wanted to change my sound settings, I could quickly locate this in each of the files and change the numbers. This is what makes them great for configuration files.
Each of these formats has its own pros and cons. The INI file is easier for a human to read since it’s lacking the less-than and greater-than symbols of the XML and the curly brackets and double quotes of JSON. The INI is not so great for more complex data, such as nested information or complex lists. XML can accommodate more complex data, but it does not have data types like JSON.
In addition to the pros and cons for each data format, ease of parsing by the language/framework being used is also important to consider. If a JSON parser is already being used heavily by your application, then JSON may be the best fit for your configuration file.
In Chapter 9, we took a brief look at Node.js with JSON on the server side. A good real-world example of JSON as a configuration file is the JavaScript package manager that is the default for Node.js: npm. It is also used by other frameworks such as AngularJS and jQuery.
The npm package manager uses JSON as a configuration file called package.json. The package.json file contains information specific to each package, such as the name, version, author, contributors, dependencies, scripts, and licensing (see Example 10-4).
Example 10-4. An example package.json file for npm
{
"name": "bobatron",
"version": "1.0.0",
"description": "The extraordinary library of Bob.",
"main": "bob.js",
"scripts": {
"prepublish": "coffee -o lib/ -c src/bob.coffee"
},
"repository": {
"type": "git",
"url": "git://github.com/bobatron/bob.git"
},
"keywords": [
"bob",
"tron"
],
"author": "Bob Barker <[email protected]> (http://bob.com/)",
"license": "BSD-3-Clause",
"bugs": {
"url": "https://github.com/bobatron/issues"
}
}
Though JSON is sitting in one place as a configuration file, it is still playing the role of a data interchange format. In the case of a settings file that sits in a directory somewhere, the interchange is happening between the human and the computer. The data is communicated.
The Big Picture
As a configuration file sitting on a server, or a resource being requested by a URL, JSON is doing its job as a data interchange format. We’ve explored these jobs (or roles) in the chapters of this book. Let’s do a big picture recap of how JSON is being used out in the world today.
On the server side, objects can be serialized to the JSON text format, and deserialized back into an object. JSON can also be requested from the server-side code. We saw this in action with both the ASP.NET and PHP examples discussed in Chapter 9.
Additionally, JSON is a text format that can also be used as a document for a document store type of database. We saw this in Chapter 8 with CouchDB. This database was also interfaced with through an HTTP web API.
An HTTP web API provides a request and response system for resources such as HTML and JSON documents. These documents are requested via HTTP with a URL. We also saw this in Chapter 6 with the OpenWeatherMap API providing weather data as JSON resources.
The JavaScript XmlHttpRequest can request a JSON resource from a URL. To use the JSON in the JavaScript code, we must deserialize the JSON to a JavaScript object. This is quickly achieved with the built-in JavaScript JSON.parse() function.
From a JavaScript object, to the JSON format, to an object on the server, we can see the data move full circle. Every day data moves in and out of systems around the world, and that data is in an interchange format.
If we again take a look from 6,000 feet, we can see that JSON is not alone as a data interchange format. Some data is being moved around in a comma-separated values (CSV) format, or an Excel format. Both are tabular. Other data is being moved in an XML format, which supports nesting of data.
Data has many formats, and many shapes. Systems that push out and receive data in these formats are diverse. Both the shape of the data and the systems interchanging the data have to be considered when choosing a format for data interchange. As much as this book loves JSON and views it as a fantastic format for data, JSON is not always the answer.
For example, let’s say two systems needed to communicate inventory data, and those two systems both stored that information in a tabular format. Would it make sense to convert that tabular data into an object format, serialize to JSON, convert back into an object format, and then back into tabular data again? No, in that case we’d be adding extra steps just for the sake of JSON. A more appropriate format for this data would be a tabular one, such as CSV or tab delimited.
JSON is a popular format for data interchange because many systems are modeling data as objects. The data is often being stored in a relational database. Though the tables of relational databases are tabular, the relationships in the data are broken out into entities that can be seen as objects. Each entity, such as an address, has “fields” that are essentially name-value pairs.
In systems such as an Internet browser, where JavaScript supports object-oriented programming, JSON is ideal for interchanging data. JSON is great in JavaScript for communicating with web APIs and creating AJAX interactions.
In systems such as a server-side web framework that is object oriented, JSON is ideal for interchanging data. JSON shines for data by maintaining its structure as an object literal as it moves in and out of the system.
Like the example in “JSON as a Configuration File”, the pros and cons must be examined for choosing a format. It all boils down to the right tool for the right job.