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 dynamicall 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.
You ever need to create a dictionary?
Of course you do! Heck, I do it all the time!
Oh, stop looking at me like that. I don’t just mean language dictionaries! Address books, blogrolls, bibliographies, calendar events grouped by date… anywhere you have a list of words/phrases/terms/names/etc. and their corresponding definitions/explanations/details/etc., you’ve got a dictionary.
For example, suppose you wanted to create a list of tourist attractions in your favorite city:
Cerro San Cristóbal: A really big hill on the north side of town.
La Vega: Awesome place to buy veggies.
Patio Bellavista: Great nightlife and dining.
I’m going to go ahead and take the liberty of assuming that your favorite city is Santiago de Chile, but if this is completely unacceptable to you, feel free to follow along with your own list.
Not too shabby. Now, let’s tweak it a little bit by putting everything in quotes:
"Cerro San Cristóbal": "A really big hill on the north side of Santiago."
"La Vega": "Awesome place to buy veggies."
"Patio Bellavista": "Great nightlife and dining."
And just so that it’s clear where each entry in the list ends, we’ll add a comma at the end:
"Cerro San Cristóbal": "A really big hill on the north side of Santiago.",
"La Vega": "Awesome place to buy veggies.",
"Patio Bellavista": "Great nightlife and dining."
And for good measure, let’s decorate it with some curly braces because they’re just so goshdarned pretty:
{
"Cerro San Cristóbal": "A really big hill on the north side of Santiago.",
"La Vega": "Awesome place to buy veggies.",
"Patio Bellavista": "Great nightlife and dining."
}
Well, would you look at that — we now have ourselves a properly-formatted JSON object! Not only is it still perfectly readable by humans, but you can now feed it into a script in just about any language.
And since most JSON readers don’t mind a little whitespace, you can make it even prettier:
{
"Cerro San Cristóbal":
"A really big hill on the north side of Santiago.",
"La Vega":
"Awesome place to buy veggies.",
"Patio Bellavista":
"Great nightlife and dining."
}
With a little bit of JSON, you can easily create attractive definition lists that are readable both by humans and computers!
From time to time, your data models might suffer from field creep — you have to keep adding more and more fields to your models to work around edge cases and unique business requirements.
In the world of relational databases, this usually manifests either as additional fields tacked onto an existing table, or a separate “detail” table with a one-to-one relation to its corresponding source model — and these are just the least complicated approaches; there are far more complex ways to address the situation!
One approach to addressing the need for ever-more-specific-use-case fields: add more (increasingly ridiculously-named) fields to the table.
An alternate approach: move all of those pesky “detail” fields into a separate table that you can hide away in the closet whenever company comes over.
In addition to cluttering up your ERD, you are also leveraging the power (and overhead!) of your relational database engine for things that don’t actually need it.
Your pet store application might never need to filter a select query by userstory183274_marker value, but thanks to user story 183274, you still have to store that information with each pet.
Perhaps there’s another approach, one that is more scalable and doesn’t clutter up your database tables with (almost) useless fields… and yet still makes this custom information accessible to your application.
Well, as it happens, there is! Combine all of those extra “detail” fields into a single detail field that uses – you guessed it – JSON to store key/value pairs!
Much easier on the eyes!
Let’s peek at some values in our newly JSON-ified Pet table:
| pet_id | owner_id | species_id | name | detail |
|---|---|---|---|---|
| 1 | 1 | 1 | ‘Bowser’ | {"collar_manufacturer": "PetProtector", "rabies_flag": true} |
| 2 | 1 | 2 | ‘Oliver’ | {"has_name_tag": false, "music_preference": "Light Jazz"} |
| 3 | 2 | 1 | ‘Marcus’ | {"userstory183274_marker": "FILENOTFOUND"} |
Notice that in the time it took to draft up this table, we added a new feature: Musical Preference. Oliver likes Light Jazz.
Some of the benefits of storing “extra” data about your models this way:
There are a few costs to this approach that you should be aware of, however:
For storing one-off properties and flag values that you only need at the application level (i.e., you do not need to index/filter/search these values), think about whether you can store these values in a single JSON-formatted string instead of bloating your tables with extra fields.
And if you find that you’re using this feature a lot in your relational-database-powered application, you might want to consider whether a NoSQL solution such as CouchDB is a better fit for some or all of your data!