JSON is a data interchange format (or serialization format.) If you have some object and you want to store it in a file or send it over a network connection or something of that nature, you have to convert it to a string first, because you can't send objects over a network or write objects to a file. You can only write strings. And the other end has to receive that string and reconstitute it into an object before it can work with it. JSON is a set of rules for how to turn objects into strings and vice versa. It's based on JavaScript syntax, but it's not specific to JavaScript; it's used by many other languages. Its cousins are other serialization formats such as YAML and XML.

toString() is completely useless for this. When invoked on an object, it evaluates to the string "[object Object]". Example:

> var obj = {foo: 42, bar: [1, 2, 3], baz: "hippo"};
undefined
> obj.toString();
'[object Object]'
> JSON.stringify(obj);
'{"foo":42,"bar":[1,2,3],"baz":"hippo"}'

Note that in this example you could have just put quotes around the object literal, but that's missing the point. You don't always have an object literal. The object could have been built by much more complicated means. This is just a simple example.

Javascript object notation.

Its a way of sending and receiving data in a certain format. In the old days if I wanted to exchange data with (for example) Hertz I might call them up and agree to send them a fixed width or comma separated values (CSV) file with request information and they might agree to send a similar fromatted response file or a completely different format. If my colleague contacted them they might also agree on an interface but his request file might be a different format to mine and their response might also be a different format. Hertz may want a fixed width request file but Budget may want me to send a CSV request file. So loads of different interfaces existed (Hertz may be different to Budget, who are also different from AVIS etc.). And Im just using rental car companies as an example - loads of different comanies have interfaces and exchange information all the time.

My request file to Hertz (formatted as we agreed):

REQUEST=WhoIsDriver, DATE=01/01/2010, Plate="XYZ 1234"

Their response (formatted however they choose):

DRIVER:JoeSmith, CAR:Ford, MODEL: Explorer, FROM: 12/30/2009, TO: 01/07/2010

So in the old days it was truly random with all sorts of interface formats whcih were proprietary to whoever designed them Then came along XML, which was. better in that it forced a certain kind of syntax but it was very wordy

<request>
  <type>WhoIsDriver</type>
  <date>01/01/2011</date>
 <plate>XYZ 1234</plate>
</request>

This was very popular and the forced formatting meant lots of standardized services appeared on the WEB saying if you send us data formatted in XML in a certain way we will send back information to you also formatted in XML. Google SOAP interfaces for more info on this.

But in a trifector of luck/timing/ whatever:

1. XML is very wordy, If you have an interface with 10,000 requests and responses the file sizes get huge because of all the <start-tag>...<end-tag> stuff, and this makes things slow.

2. everyone is slowly moving to new shiny web front-ends for their systems and therefore having to use Javascript, and

3. Javascript have a nifty less wordy way of representing data - their Javascript object notation (also called JSON).

So slowly but surely, JSON is taking over the world in interfaces between companies and also many public interfaces (such a Google maps) that used to be XML only are now becoming REST services/interfaces that use JSON format for data exchange.

Javascript (JSON) format is:

{ "type" : "WhoIsDriver", "date" : "01/01/2011", "plate" : "XYZ 1234" }  

In the web development world we frequently have to pass data from the front-end programs in the browser to the back-end programs on the server. This is also an interface and nowadays most data is passed on JSON format.

JSON is a convention or protocol for formatting and structuring data you want to store. The basic idea is that information and data is very important just in general for just about anything you might possibly might want to do, which means being able to easily access and manipulate the data you own is also very important.

When you have information (demographic data, some representation of a CAD model, numbers computed from research, whatever), you could just take that data, chuck it into a text file, and write some custom code to try and extract and write to that file in some manner. This however is somewhat of a fragile solution since anybody else who wants to work with your data would also need to write some custom code to parse however your data is formatted.

This is obviously sub-optimal -- being able to freely exchange and work with data is nearly as important as the data itself.

So, what people did was invent standards for how data should be formatted and structured (and took care to make sure those standards were flexible enough to represent all kinds of data). The idea is then that if somebody creates a library that can understand and work with that format, everybody else can use that library without having to constantly reinvent things. As they say, don't reinvent the wheel.

XML is one such standard. CSV is another. JSON is yet another. There are many.

JSON, in particular, was designed to be simple and minimalistic. The rules for what constitutes a valid chunk of JSON were designed to very basic and straightforward, and to closely mimic data structures and primitive types that many programming languages have built-in by default.

For example, here is a basic example of some invented data I came up with structured in JSON format:

{
    "data-type": "posts",
    "posts": [
        {
            "title": "Comment 1",
            "body": "..."
        },
        {
            "title": "Comment 2",
            "body": "..."
        }
    ]
}

If you have any experience working with languages like JavaScript or Python, you'll notice this looks identical to dict, list, and string literals. This resemblance is identical.

For comparison is how you might decide to structure this same data in a different format, XML:

<data type="posts">
    <comment>
        <title>Comment 1</title>
        <body>...</body>
    </comment>
    <comment>
        <title>Comment 2</title>
        <body>...</body>
    </comment>
</data>

Learning JSON (or XML or any data exchange format) is not typically the hard part and is typically easily learned and mastered. Working with the underlying data as well as tools that can manipulate your data, store it into various forms may potentially be hard.