Hi, meet my friend JSON.

Chances are you’ve heard of it, perhaps you have a vague idea of what it’s for – something to do with data-interchange – perhaps you even suspect that the J stands for Javascript… or is that Java?

The rise in JSON’s popularity has been pretty meteoric, from its early days back in the year 2001 to these days when it has elbowed room for itself alongside XML at the top table. Some say it has even supplanted XML.

But, before we get carried away, let’s go back to the start. You were right, the J in JSON is Javascript – and so is the S, actually. JSON stands for JavaScript Object Notation, and it’s a format for storing data. Although, saying it’s just a format for storing data is kinda like saying Beyoncé is someone who sometimes sings in the shower. As a means for storing and exchanging data, JSON has some attributes that make it stand out:

  • It is lightweight.
  • It is, despite the JavaScript in its name, language-independent.
  • It is easily human-readable. And it’s easy to write too.
  • It is easily parsed – and generated – by a growing number of programming languages.
XML vs JSON

Now, I know there’s at least one person, dressed in his I ♥ XML underpants and looking distinctly unimpressed. Yes, all of these descriptions can be – and have been – applied to XML. And the XML versus JSON rivalry can be as fierce as that of the Capulets and the Montagues, or, I dunno, Freddy vs Jason, but JSON does have some advantages over XML.

  • It is shorter or, in other words, even more lightweight.
  • It is even more easily human-readable. And writeable.
  • It is less strict which, at a stretch, is another way of saying it’s perhaps even more easily parsed by programming languages.
  • Additionally, with JSON it is much easier to work with arrays.

XML does dunk on JSON in some ways too, though. One reason I said JSON is less strict, for example, is that it does not have namespaces. This robs it of a means of sharing standard structures. JSON also doesn’t allow for comments. Or have the concept of schemas.

In truth, despite their surface similarities, the way they are used seems to be diverging every day. Your Ajax interchanges, these days, might be more likely to be in JSON, while your large scale file-based data exchanges might be XML.

Structure

JSON is text-based and is built on two simple structural pillars, objects and arrays. A JSON object is made up of one or more name:value pairings, cuddled up within the bounds of two curly braces. A valid JSON object has the following syntax:


Source: json.org

Building on this you can have arrays. You could, for instance, group a number of objects within square brackets to make them an array. But it’s not just objects that you can construct an array out of; it’s any value. The syntax for a JSON array is as follows:


Source: json.org

Let’s unpack that for a moment. In talking about both objects and arrays, we’ve mentioned values. In JSON, any of the following qualifies as a valid value:

  • String
  • Number
  • true
  • false
  • null
  • Object
  • Array

Since both objects and arrays can be used as values – and therefore used within other objects and arrays – we’re basically saying that JSON allows nesting, and, because of this, is malleable enough to stretch from containing very simple data to containing quite complex relationships.

Examples

But let’s not get ahead of ourselves. An example would probably help here. This is some simple JSON containing basic information about me.

{
  "firstname":"David",
  "lastname":"Njoku",
  "occupation":"Software developer"
  "gender":"Male"
}

If, however, we wanted to store information about my whole family, we might resort to an array.

[
  {
    "firstname":"David",
    "lastname":"Njoku",
    "occupation":"Software developer"
    "gender":"Male"
    "isAdult":true
  },
  {
    "firstname":"Sola",
    "lastname":"Njoku",
    "occupation":"Radio producer"
    "gender":"Female"
    "isAdult":true
  },
  {
    "firstname":"Moyo",
    "lastname":"Njoku",
    "occupation":null
    "gender":"Male"
    "isAdult":false
  }
]

Let’s move things around a bit. To demonstrate the fact that JSON supports nesting – and to illustrate its flexibility – I’ll represent the same information nesting an object within another.

{
  "father":  {
   		 "firstname":"David",
                 "lastname":"Njoku",
   		 "occupation":"Software developer"
   	 	 "gender":"Male"
   		 "isAdult":true
  	      },
  "mother": {
   		 "firstname":"Sola",
                 "lastname":"Njoku",
   		 "occupation":"Radio producer"
   	 	 "gender":"Female"
   		 "isAdult":true
  	      },
  "child":   {
   		 "firstname":"Moyo",
                 "lastname":"Njoku",
   		 "occupation":null
   	 	 "gender":"Male"
   		 "isAdult":false
  	      }
}

Or if you’d prefer data you’re more familiar with let’s express a few rows from the EMP table in both XML and JSON.

  
<emps>
  <emp>
    <empno>7839</empno>
    <ename>KING</ename>
  </emp>
  <emp>
    <empno>7698</empno>
    <ename>BLAKE</ename>
  </emp>
  <emp>
    <empno>7782</empno>
    <ename>CLARK</ename>
  </emp>
</emps>

Putting the same information in JSON allows us revisit some of the points we were making earlier about how, for example, it whups XML’s behind when it comes to brevity and readability.

{"emps": {
  "emp":[
    {"empno":7839, "ename":"KING"},
    {"empno":7698, "ename":"BLAKE"}    
    {"empno":7782, "ename":"CLARK"}   
  ]}
}

Translating the EMP table into both XML and JSON does suggest to me one other possible point in the XML or JSON debate: Oracle support. We know that Oracle’s XML functionality is deep and extensive. In the next article in this series we’ll look at the relationship between JSON and Oracle.

Tags: