An Introduction to JSON

JSON stands for JavaScript Object Notation. It is a data interchange format, which is a fancy means of saying it’s a way of storing and transferring data. It has become widely deployed for quite a large number of use cases. And although the name implies JavaScript, JSON is used with other languages, such as Python, Ruby, PHP, and Java. More important, however, the JSON format is also used for Docker and Kubernetes manifests, so it’s absolutely crucial to understand how JSON works for anyone interested in cloud native development.

JSON came about as a subset of JavaScript in December of 1999 when object literals and array literals were added to JavaScript. JSON quickly became language-independent, such that almost every programming language was capable of parsing JSON data.

JSON wasn’t really invented by anyone in particular, as a number of different people realized how functional this data transfer/storage system would work. The term “JSON,” however, was coined by Atari employee Douglas Crockford. In 2002, Crockford went on to register the json.org domain. Crockford had become quite an important figure in technology (working at companies like Paypal), so his voice was instrumental in spreading the JSON word.

However, it wasn’t until the advent of the Single Page Application (SPA) that JSON usage really exploded, as both mobile and web applications required a seamless interchange of data. This is due to the succinct format of JSON data being considerably more efficient at sending data back and forth to a server, as compared to XML. One of the reasons for that is because JSON is a much more efficient and succinct language.

Here’s an example of XML:

<colors>
    <color>
        <colorname>Black</colorname> <hex>000000</hex>
    </color>
   <color>
        <colorname>White</colorname> <hex>FFFFFF</hex>
     </color>
     <color>
         <colorname>Red</colorname> <hex>FF0000</hex>
     </color>
</colors>

The JSON code for the above would be something like this:

{"colors": [
   {"colorname" : "Black", "hex" : "000000"},
   {"colorname" : "White", "hex" : "FFFFFF"},
   {"colorname" : "Red", "hex" : "FF0000"}
]}

As you can see, the JSON is not only much easier to write but easier to read.

JSON files use the .json extension but don’t be fooled into thinking you can only use JSON in .json files. In fact, all .yml and .yaml files are written in the JSON format, which (given how many applications and services depend on YAML files) is why it’s important to understand what JSON is and how it’s structured. If you want to deploy a container to a Kubernetes cluster, you’ll be using JSON. Want to build a Dockerfile, that’s right, you’re using JSON. There are even configuration files for desktop and server applications that depend on the JSON format.

Speaking of which…

JSON Structure

JSON files (be they .json, .yaml, or just about any file that depends on JSON) are built with two primary components:

• A collection of name/value pairs.
• An ordered list of values.

The structure of a JSON file is very much dependent on key-value pairs. Let’s say you want to build a JSON structured file that includes information about a user. That structure might look like this:

{
  "f_name" : "Jack",
  "l_name" : "Wallen",
  "gender" : "Male",
  "profession" : "Writer"
}

In the above example, we have four key-value pairs:

• f_name – Jack
• l_name – Wallen
• gender – Mail
• profession – Writer

Each pair is always set up in the form:

“key” : “value”

Both keys and values must be wrapped in double quotes. Keys always go to the left side of the colon and values on the right. Within each object, every key must be unique and can contain spaces. So, instead of “f_name”, you could use “first name”. However, I always avoid using spaces in keys, as it can get confusing.

Values are found on the right side of the colon and must be one of six data types:

• Strings
• Numbers
• Objects
• Arrays
• Booleans
• Null

You can also create a key-value pair using a nested object. Such a structure might look like this:

"user" : {
"f_name" : "Jack",
"l_name" : "Wallen",
"gender" : "Male",
"profession" : "Writer"
}

Above we have a key of “user” and a nested list of key-value pairs, consisting of “f_name”, “l_name”, “gender”, and “profession.

We can also use arrays within our key-value pairs. Arrays are housed with [ ]. Let’s continue with our example above, but we’ll add two more values to the “profession” key with an array. That would look like this:

"user" : {
"f_name" : "Jack",
"l_name" : "Wallen",
"gender" : "Male",
"profession" : [ "Writer", "Actor", "Technologist"]
}

Both of these examples bring up a very important point—indention. One of the caveats to using the JSON format is that indention absolutely must be consistent. As you can see above, my braces line up with one another as do my nested key-value pairs. If your indention isn’t consistent, whatever you’re using the JSON format for will not work. This is often a very challenging bit to debug, especially when your JSON-formatted manifests grow in length and complexity. Because of this, it’s always important that you indent with consistency from the very beginning.

JSON format can also be written out in a single line. Let’s take, for example, our “user” object. Instead of writing it out this way:

"user" : {
"f_name" : "Jack",
"l_name" : "Wallen",
"gender" : "Male",
"profession" : "Writer"
}

We can write it as a single-line string like so:

"user" : { "f_name" : "Jack", "l_name" : "Wallen", "gender" : "Male", "profession" : "Writer" }

Although you might think the above is easier to write out, in very long documents (especially when an array can become rather lengthy), the multi-line format is much easier to manage. This is especially so when crafting very complex container manifests.

Today, JSON is used everywhere: in SPAs, in local application configurations, in container manifests, in cloud native development, and APIs. You name it, and JSON is probably a part of it.