Do you know your JSON?

6th October 2014 0 Comments

With the Halloween fast approaching, we wanted to share with you the biggest differences between the world’s most famous Jason – from Friday the 13th and JSON, our best friend at DataSift.

Once upon a time, there were a bunch of web services that wanted to exchange data with one another. The problem was, these services were all written by different groups of developers and they did not communicate with each other about how data should be exchanged: what it should look like, how it should be generated, how their respective services should parse and consume it, and so on. Enter JSON, or JavaScript Object Notation, which uses a simple format to exchange data between web servers, typically over an open API.

The whole point of JavaScript Object Notation, or JSON, is to make exchanging data between applications and services both easy and quick—easy, because it is a standardized way to represent objects that both the sender and receiver can agree on, and quick, because it is lightweight, does not have a ton of overhead, and is designed to be used both internally and over the Internet or other somewhat unreliable mediums. Prior to JSON, data was exchanged between servers and services and browsers primarily with third party plugins or platforms, like Java or Flash.

Let us delve into why JSON is easy—at least comparatively so—a little bit more. JSON is at its core human readable, which makes it very simple to both generate, debug, and consume. It is not hard to write services that export data via JSON nor is it difficult to develop routines to process incoming data via JSON; in fact, the standard code for reading and processing JSON as well as making your own JSON is already available in almost all programming languages today, including all of the languages commonly in use in development—so getting started with it and learning how to deal with it is not a Herculean task.

JSON is almost exclusively pairs of attributes and related values that describe something. For instance, if you wanted to write a JSON representation of a person, here is how you might describe him:

        "firstName": "Alan",
        "lastName": "Jones",
        "age": 33,
        "address": {
        "streetAddress": "123 Main St.",
        "city": "Any Town",
        "state": "DC",
        "usZipCode": "12345"
    "telephoneNumbers": [
            "place": "work",
            "number": "123-456-7890"
            "place": "cell",
            "number": "987-654-3210"

You might be wondering why, if data exchange between services is really the primary point of JSON, you would not want to simply use XML, or the extensible markup language. You could. However, XML has more overhead to it, but typically XML uses more expansive descriptions which would make representing the same something in XML require more bandwidth and processing power than presenting that exact same thing in JSON. XML also has a much more formal schema and is more structured, where as JSON is much more freeform. A draft standard schema is available, but typically the use of JSON evolves as business needs drive, and there is less reliance overall on a true schema than there is in the XML world. JSON also handles mixed content much more reliably than any other data exchange format that is out there today, so it lends itself to uses where you have all sorts of content and not simply static data.

What does JSON have to do with JavaScript? Other than sharing a name, not much, honestly. You will find JSON commonly used in JavaScript based applications, and at first, JSON was developed and based on a subset of the JavaScript scripting language, but JSON is in fact completely language independent and you are just as likely to find JSON used with PHP and Laravel and Ruby on Rails as you are in JavaScript. Remember, JSON is first and foremost a format for sharing data—not a format for a language. Any language that can generate and parse it is just fine from the standpoint of using JSON.

Where does JSON fit in with us at DataSift? It figures squarely into the equation: DataSift’s data processing output is in JSON, so our customers have to be able to consume it readily. For example, straight out of the developer resource for DataSift, here is an example of the JSON formatted output you get when you activate our Twitter feed:

    "interaction": {
        "source": "TweetDeck",
        "author": {
            "username": "stewarttownsend",
            "name": "Stewart Townsend",
            "id": 14065694,
            "avatar": "",
            "link": ""
        "type": "twitter",
        "link": "",
        "created_at": "Tue, 15 Nov 2011 14:17:55 +0000",
        "content": "Morning San Francisco - 36 hours and counting.. #datasift",
        "id": "1e10f949c51aab80e074df944f5e8e46"
    "twitter": {
        "user": {
            "name": "Stewart Townsend",
            "url": "",
            "description": "Developer Relations at Datasift (  - Car racing petrol head, all things social lover, co-founder of",
            "location": "iPhone: 53.852402,-2.220047",
            "statuses_count": 28247,
            "followers_count": 3094,
            "friends_count": 510,
            "screen_name": "stewarttownsend",
            "lang": "en",
            "time_zone": "London",
            "listed_count": 221,
            "id": 14065694,
            "id_str": "14065694",
            "geo_enabled": true
        "id": "136447843652214784",
        "text": "Morning San Francisco - 36 hours and counting.. #datasift",
        "source": "<a href="" rel="nofollow">TweetDeck</a>",
        "created_at": "Tue, 15 Nov 2011 14:17:55 +0000"

If you do not know JSON or are not yet ready to embrace it, our best advice to you is to start now. JSON is the lightest, simplest, and most versatile way to exchange data between applications.

Comments are closed.

Share This