JSON: What it is, and what it isn’t

What JSON is

JSON is a data interchange format similar to languages such as XML and YAML. Its language independence allows programing languages to communicate with each other, though the process of stringification and parsing.

The popularity of JSON can be put down to its simplicity; it is easy for both humans and computers to read, and its language encompasses most of the types which are common across modern web languages. Furthermore, it is considerably more lightweight than other exchange formats such as XML. Variations of JSON such as BSON reduce the size of a JSON representation even further.

The syntax of the language bears a strong resemblance to the JavaScript programming language; this is no coincidence as the language was suggested by Douglas Crockford, a name known to many due to his contributions to the JavaScript language. The standardised version of the language (RFC 4627) supports the following types:

  • Number
  • Boolean
  • Null
  • String (characters captured with double quotes)
  • Ordered lists (comma separated types captured by “[“ and “]”)
  • Unordered sets (comma separated string:type pairs captured by “{“ and “}”)

You can easily check if a string is valid JSON by entering its contents on the jsonlint.com website. For more detailed explanations of the valid JSON types, see the json.org website.

What JSON isn’t

It is all too common for developers to get confused as to what JSON is; particularly amongst the circles of web developers. This confusion can no doubt be put down to JSON’s similarity to JavaScript.

JSON is nothing more than a data format. Once the JSON formatted string has been received by the programming language, it is usually parsed immediately into a language dependant structure; such as an array or an object. Likewise in the reverse, something is only “JSON” when it has been stringified from a language dependant type (such as an array or an object) into a valid JSON string.

This concept is so often misunderstood that I shall try an analogy to enforce the point; imagine you are purchasing a piece of flat pack furniture, but the only one left in stock is the display model, which you agree to purchase. The display model is dissembled from a usable product and packaged in a box (read: stringification). The packaged box is now in a format equivalent to JSON; it is unusable in every sense, but provided the sender has a postbox (read: stringifer), and the receiver a letter box (read: parser), it can be handled. Upon being received, the product has to be assembled (read: parsed) for it to become usable again.

Another common misconception is that JSON is AJAX or vice versa. AJAX is a buzz word for a group of technologies available within browsers which allow a developer to make HTTP(s) requests on demand/ asynchronously. AJAX does not specify (nor does it care) what format the HTTP(s) response is in; JSON is just one available option, along with HTML, XML and JSONP.

Continuing with the posting-flat-pack-furniture theme, AJAX can be likened to the cardboard packaging used to transport products; it does not care whether it ships a bed (read: JSON), a table (read: XML) or a wardrobe (read: HTML).

Lastly, the syntax shared between JavaScript and JSON often leads to some confusion as to what JSON is. The syntax of JSON is subset of JavaScript syntax; meaning that all valid JSON is valid JavaScript, but not vice versa. For instance, JSON does not support the types undefined, function or Date. Another common mistake is to believe that values surrounded by single quotes ('foo') is valid JSON string; however a JSON string must be surrounded by double quotes ("foo"). Additionally, whilst the object literal syntax in JavaScript is similar to that of JSON’s unordered set, it should be noted that the key to a JSON unordered set must be a string, whilst JavaScript’s object literal syntax accepts either a number, or the toString() version of any other type.

Leave a Reply

Your email address will not be published. Required fields are marked *