JSON.com is a collection of JSON related content, links, and general awesomeness hand selected by the good people of the Web. The original json.com site has been archived.
JSON.com has existed on the Web since 2006. It’s changed hands a number of time looking for a sustainable home.
BigBlueHat has most recently offered to curate a community via the collaborative awesome of GitHub.
If you are interested in participating, please reach out via GitHub. Send in Pull Requests with openly licensed content, links, etc.
Let’s build this one to last. 
In developing web applications it’s commonplace to send and receive data to APIs (Application Programmable Interfaces) that exist on other domains. This cross-domain communication is often performed directly in the browser, on the client-side using JavaScript. Cross-domain communication can be accomplished using a server-side languages like Python, Nodejs, PHP, etc., however for cases where responses from cross-domain requests are utilized in the browser, JavaScript can save time and simplify development. Addintionaly, JavaScript requests are asynchronous— meaning they can be run in parallel with other processes. For example, JavaScript requests to other domains can be processed asynchronously while the page is still loading.
Same-origin policy is an important security concept in client-side programming languages including JavaScript. This policy is observed by all web browsers and limits scripts running on a site to only sending requests with the same site. Browers use a combination of port number (e.g. 80) and hostname (e.g. my.domain.com) to determine the scope of the ‘site’. There are however exceptions to the same-origin policy, including using the HTML <script> tag to retreive a dynamically generated JavaScript file from an external site. The most prominent of method of exploiting this exception is JSONP.
JSONP uses the <script> tag to retreive remote JavaScript code containing formatted JSON data with a function call wrapped around it. The data is not parsed, rather it is evaluated by the JavaScript interpreter.
A typical JSONP request may look like:
<script type="application/javascript"
src="http://remote.domain.com/data/?callback=jsonpcallback&id=123">
</script>
The dynamically generated JavaScript file may look like:
jsonpcallback({
"id": "123",
"comments": "6",
"name": "sample"
});
The “padding” in JSONP refers to the function call that wraps the formatted JSON object. This padding isn’t always a function call. Though not common, padding could also be a variable assignment:
var data = {
"id": "123",
"comments": "6",
"name": "sample"
};
The purpose of the padding is to allow a means for the formatted data to be put to use in the application.
The jQuery JavaScript library has functions to make using JSONP a snap.jQuery’s $.ajax() function will automatically handle <script> tag injection and response handling (i.e. calling the ‘callback’ function).
$.ajax({
//JSONP API
url: "http://remote.domain.com/data/?callback=jsonpcallback&id=123",
//the name of the callback function
jsonp: "jsonpcallback",
//tell jQuery to expect JSONP
dataType: "jsonp",
//tell YQL what we want and that we want JSON
data: {
id: "123"
},
//work with the response
success: function(data) {
console.log(data); //formatted JSON data
}
});
console.log(data);
{ "id": "123", "comments": "6", "name": "sample" }
Alternatively, if jQuery is not available- which is often the case when developing embeddable widgets- raw JavaScript can be used. The following is minimal JSONP implementation:
//callback function
function jsonpcallback(data) {
//do stuff with JSON
console.log(data);
}
//create HTML script tag
var script = document.createElement('script');
script.src = "http://remote.domain.com/data/?callback=jsonpcallback&id=123"
//inject script tag into head
document.getElementsByTagName('head')[0].appendChild(script);
What does “bootstrapping” mean exactly? Hard-coding your data to the page using synchronous server-side template.
Most developers face the challenge of sending data from their server-side to the client-side to be used JavaScript. There are several solutions for this. Among the most common is creating an REST endpoint that can be consumed with asynchronous javascript, often using the jQuery Ajax function.
Depending on the answers to these questions, bootstrapping may be an elegant solution for getting the data to the client-side quickly and with minimal development.
It typically looks something like this on the server side:
<script type="text/javascript">
//bootstrapped data with server-side template
var bootstrap = {
"app_id": "",
"session_id": "",
"title": '',
"price": "",
"confirmation": ""
};
</script>
It looks like this when it’s rendered on the client side:
<script type="text/javascript">
//bootstrapped data rendered on client-side
var bootstrap = {
"app_id": "a1b2c3",
"session_id": "x0y9z8",
"title": "My Cool App",
"price": "1.99",
"confirmation": "Thanks for purchasing our app."
};
</script>
This boostrapped JSON object can now be called with JavaScript immediately when the object is rendered by the browser:
console.log(bootstrap)
// { "app_id": "a1b2c3", ... }
console.log(bootstrap.title)
// My Cool App
Note: it’s best to put the bootstrapped object near the top of the page so it can used immediately, even before remaining html/css/javascript is loaded.
The key benefit of the bootstrapped object comes in the time saved when
not having to use asynchronous JavaScript to call data from a REST
endpoint. If you typically use jQuery Ajax to do this, 100-500
milliseconds of prerequsite load time would be added just to gain access
to the jQuery.ajax() function. Any ajax request(s) retreiving data
from a REST endpoint comes with additional load time expense.
If your app depends on this data, synchronously loaded (aka “bootstrapped”) JSON data will make your app snappy and your users happy. Not to mention, because of the server-side templating, REST endpoint security considerations are nullified.
The use of nested JSON object often allows developers to break out of the common relational schemas employed in databases like MySQL and MSSQL. When not limited to a shallow data schema based on rows and columns, data can take on new strucutres to better align with development needs. When JSON is used in a persitence layer, nested objects can often be used to replace simple relationships that might have existed in a relational data schema.
An example of an ‘employee’ object stored in JSON.
{
"id" : "1",
"f_name" : "Adam",
"l_name" : "Smith",
"skills" : [
"web development",
"ux design",
"data science"
],
"team": "engineering"
}
Nesting like this can greatly simplify data storage and make data more easily digestible and traversible by an app. Unlike data stored in rows and columns, JSON can be structured to be infinitely deep. Objects can be nested inside objects, nested inside objects, etc..
A similar dataset to the above might look like the following in a relational data schema:
| id | f_name | l_name | team |
---------------------------------------------
| 1 | Adam | Smith | engineering |
| id | name |
---------------------------
| 1 | web development |
| 2 | ux design |
| 3 | data science |
| id | employee_id (fk) | skill_id (fk) |
---------------------------------------------
| 1 | 1 | 1 |
| 2 | 1 | 2 |
| 3 | 1 | 3 |
In this case, to define the relationships between skills and employees we’re forced to use three tables, each with a rigid structure. The cost-benefit of JSON is evident, especially if data storage requirements ever change. Imagine the cost of maintaining 3 tables versus one flexible JSON object. Not all data is suited for JSON. For those who value maintainability and flexibility over rigid schemas, it’s a fantastic alternative—one increasing greatly in popularity.
JSON is a attractive option for setting up a custom analytics data store. The flexibility of JSON allows for website owners flexibly store data and get creative in changing tracked data over— all without worring about changing a database schema.
Here’s an example of what an object containing analytics data might look like:
{
"_id":"0e494339-c94e-4834-93e6-8f0896c5346c",
"_timestamp":"1386697259630",
"_uid":"843f8e4f888de5b9",
"_url":"http://www.mysite.com",
"_referrer":"",
"_category":"campaign",
"_action":"share",
"_browser":{
"pdf":"1",
"qt":"1",
"realp":"0",
"wma":"0",
"dir":"0",
"fla":"1",
"gears":"0",
"ag":"0",
"java":"1",
"res":"1440x900",
"cd":"24",
"cookie":"1"
},
"medium":"twitter",
"campaign_id":"1",
"product_id":"2",
"other_field": "anything"
}
Notice some fields are prefixed with an underscore— these denote ‘default’ fields while fields without an underscore are considered ‘custom’ fields. This allows as to create extend our JSON objects, while still providing the bare minimum defaults that would be used in an analytics application. Say for example, in one month of implementing analytics tracking, business requirements change and now it’s important to track a new field ‘widget_type’. Without making a change to a database schema (common with relational databases), we can add the ‘widget_type’ field to analytics object and save.
Over time as tracking requirements broaden, the size (and number of fields) in your analytics objects scales infinitely to meet. When these objects are stored with a great DBAAS (DataBase As A Service) like a(href=”http://cloudant.com”) cloudant.com data can be easily mined for interesting patterns and returned to a dashboard for further visualization. Many web-based data visualization libraries use JSON natively, so starting in this format will be an additional time-saver.