JSON

JSON

Filename extension	.json
Internet media type	application/json
Type of format	Data interchange
Extended from	JavaScript
Standard	RFC 4627
Website	json.org

JSON (/ˈdʒeɪsən/), or JavaScript Object Notation, is a lightweight text-based open standard designed for human-readable data interchange. It is derived from the JavaScript scripting language for representing simple data structures and associative arrays, called objects. Despite its relationship to JavaScript, it is language-independent, with parsers available for most languages.

The JSON format was originally specified by Douglas Crockford, and is described in RFC 4627. The official Internet media type for JSON is application/json. The JSON filename extension is .json.

The JSON format is often used for serializing and transmitting structured data over a network connection. It is used primarily to transmit data between a server and web application, serving as an alternative to XML.

History

Douglas Crockford was the first to specify and popularize the JSON format.

JSON was used at State Software, a company co-founded by Crockford, starting around 2001. The JSON.org website was launched in 2002. In December 2005, Yahoo! began offering some of its web services in JSON. Google started offering JSON feeds for its GData web protocol in December 2006.

Although JSON was based on a subset of the JavaScript scripting language (specifically, Standard ECMA-262 3rd Edition—December 1999) and is commonly used with that language, it is a language-independent data format. Code for parsing and generating JSON data is readily available for a large variety of programming languages. JSON's website provides a comprehensive listing of existing JSON libraries, organized by language.

Data types, syntax and example

JSON's basic types are:

• Number (type not specified, but in practice double precision floating-point format, as this is how JavaScript in Web browsers treats it)
• String (double-quoted Unicode (UTF-8 by default), with backslash escaping)
• Boolean (true or false)
• Array (an ordered sequence of values, comma-separated and enclosed in square brackets; the values do not need to be of the same type)
• Object (an unordered collection of key:value pairs with the ':' character separating the key and the value, comma-separated and enclosed in curly braces; the keys must be strings and should be distinct from each other)
• null (empty)

Non-significant white space may be added freely around the "structural characters" (i.e. the brackets "[{]}", colon ":" and comma ",").

The following example shows the JSON representation of an object that describes a person. The object has string fields for first name and last name, a number field for age, contains an object representing the person's address, and contains a list (an array) of phone number objects.

{
     "firstName": "John",
     "lastName" : "Smith",
     "age"      : 25,
     "address"  :
     {
         "streetAddress": "21 2nd Street",
         "city"         : "New York",
         "state"        : "NY",
         "postalCode"   : "10021"
     },
     "phoneNumber":
     [
         {
           "type"  : "home",
           "number": "212 555-1234"
         },
         {
           "type"  : "fax",
           "number": "646 555-4567"
         }
     ]
 }

Since JSON is a subset of JavaScript, it is possible (but not recommended) to parse JSON text into an object by invoking JavaScript's eval() function. For example, if the above JSON data is contained within a JavaScript string variable contact, one could use it to create the JavaScript object p like so:

 var p = eval("(" + contact + ")");

The contact variable must be wrapped in parentheses to avoid an ambiguity in JavaScript's syntax.

The recommended way, however, is to use a JSON parser. Unless a client absolutely trusts the source of the text, or must parse and accept text which is not strictly JSON-compliant, one should avoid eval(). A correctly implemented JSON parser will accept only valid JSON, preventing potentially malicious code from running.

Modern browsers, such as Firefox 4 and Internet Explorer 8, include special features for parsing JSON. As native browser support is more efficient and secure than eval(), native JSON support is included in the recently-released Edition 5 of the ECMAScript standard.

Unsupported native data types

JavaScript syntax defines several native data types not included in the JSON standard: Date, Error, Math, Regular Expression, and Function. These JavaScript data types must be represented as some other data format, with the programs on both ends agreeing on how to convert between types. As of 2011, there are some defacto standards for e.g. converting between Date and String, but none universally recognized. Other languages may have a different set of native types that must be serialized carefully to deal with this type of conversion.

Schema

There are several ways to verify the structure and data types inside a JSON object, much like an XML schema however unlike Xml schema JSON schemas are not widely used. Additionally JSON Schema have to be written manually, unlike Xml there are currently no tools available to generate a Json schema from Json data.

JSON Schema is a specification for a JSON-based format for defining the structure of JSON data. JSON Schema provides a contract for what JSON data is required for a given application and how it can be modified, much like the XML Schema provides for XML. JSON Schema is intended to provide validation, documentation, and interaction control of JSON data. JSON Schema is based on the concepts from XML Schema, RelaxNG, and Kwalify, but is intended to be JSON-based, so that JSON data in the form of a schema can be used to validate JSON data, the same serialization/deserialization tools can be used for the schema and data, and it can be self descriptive.

JSON Schema is still an IETF draft, but there are several validators currently available for different programming languages, each with varying levels of conformance. Currently the most complete and compliant JSON Schema validator available is JSV.

Example JSON Schema:

{
	"name":"Product",
	"properties":
	{
		"id":
		{
			"type":"number",
			"description":"Product identifier",
			"required":true
		},
		"name":
		{
			"description":"Name of the product",
			"type":"string",
			"required":true
		},
		"price":
		{
			"type":"number",
			"minimum":0,
			"required":true
		},
		"tags":
		{
			"type":"array",
			"items":
			{
				"type":"string"
			}
		},
		"stock":
		{
			"type":"object",
			"properties":
			{
				"warehouse":
				{
					"type":"number"
				},
				"retail":
				{
					"type":"number"
				}
			}
		}
	}
}

The JSON Schema above can be used to test the validity of the JSON code below:

{
	"id": 1,
	"name": "Foo",
	"price": 123,
	"tags": ["Bar","Eek"],
	"stock": { "warehouse":300, "retail":20 }
}

MIME type

The MIME type for JSON text is "application/json".

Use in Ajax

JSON is often used in Ajax techniques. The following JavaScript code shows how the client can use an XMLHttpRequest to request an object in JSON format from the server. (The server-side programming is omitted; it has to be set up to respond to requests at url with a JSON-formatted string.)

var my_JSON_object = {};
var http_request = new XMLHttpRequest();
http_request.open("GET", url, true);
http_request.onreadystatechange = function () {
  var done = 4, ok = 200;
  if (http_request.readyState == done && http_request.status == ok) {
       my_JSON_object = JSON.parse(http_request.responseText);
  }
};
http_request.send(null);

Note that the use of XMLHttpRequest in this example is not cross-browser compatible; syntactic variations are available for Internet Explorer, Opera, Safari, and Mozilla-based browsers. The usefulness of XMLHttpRequest is limited by the same origin policy: the URL replying to the request must reside within the same DNS domain as the server that hosts the page containing the request. Alternatively, the JSONP approach incorporates the use of an encoded callback function passed between the client and server to allow the client to load JSON-encoded data from third-party domains and to notify the caller function upon completion, although this imposes some security risks and additional requirements upon the server.

<script type="text/javascript">      
function mywiki(json)            
{        
var html=[ ];        
var ind = json.parse.text.*;        
html.push(ind);       
document.write(html);            
}  
</script>  
<script src="http://en.wikipedia.org/w/api.php?action=parse&page=Kundapura&prop=text&format=json&callback=mywiki"></script>

The above javascript code is used to get Kundapura Wikipedia Page. Browsers can also use <iframe> elements to asynchronously request JSON data in a cross-browser fashion, or use simple <form action="url_to_cgi_script" target="name_of_hidden_iframe"> submissions. These approaches were prevalent prior to the advent of widespread support for XMLHttpRequest.

Dynamic <script> tags can also be used to transport JSON data. With this technique it is possible to get around the same origin policy but it is insecure. JSONRequest has been proposed as a safer alternative.

Security issues

Although JSON is intended as a data serialization format, its design as a subset of the JavaScript scripting language poses several security concerns. These concerns center on the use of a JavaScript interpreter to execute JSON text dynamically as JavaScript, thus exposing a program to errant or malicious script contained therein—often a chief concern when dealing with data retrieved from the Internet. While not the only way to process JSON, it is an easy and popular technique, stemming from JSON's compatibility with JavaScript's eval() function, and illustrated by the following code examples.

JavaScript eval()

Because most JSON-formatted text is also syntactically legal JavaScript code, an easy way for a JavaScript program to parse JSON-formatted data is to use the built-in JavaScript eval() function, which was designed to evaluate JavaScript expressions. Rather than using a JSON-specific parser, the JavaScript interpreter itself is used to execute the JSON data to produce native JavaScript objects. However, there are some Unicode characters that are valid in JSON strings but invalid in JavaScript, so additional escaping would be needed before using a JavaScript interpreter.

Unless precautions are taken to validate the data first, the eval technique is subject to security vulnerabilities if the data and the entire JavaScript environment is not within the control of a single trusted source. If the data is itself not trusted, for example, it may be subject to malicious JavaScript code injection attacks. Also, such breaches of trust may create vulnerabilities for data theft, authentication forgery, and other potential misuse of data and resources. Regular expressions can be used to validate the data prior to invoking eval(). For example, the RFC that defines JSON (RFC 4627) suggests using the following code to validate JSON before eval'ing it (the variable 'text' is the input JSON):

var my_JSON_object = !(/[^,:{}\[\]0-9.\-+Eaeflnr-u \n\r\t]/.test(
       text.replace(/"(\\.|[^"\\])*"/g, ''))) &&
   eval('(' + text + ')');

A new function, JSON.parse(), was developed as a safer alternative to eval. It is specifically intended to process JSON data and not JavaScript. It was originally planned for inclusion in the Fourth Edition of the ECMAScript standard, but this did not occur. It was first added to the Fifth Edition, and is now supported by the major browsers given below. For older ones, a compatible JavaScript library is available at JSON.org.

Native encoding and decoding in browsers

Recent Web browsers now either have or are working on native JSON encoding/decoding. This removes the eval() security problem above and also makes it faster because it doesn't parse functions. Native JSON is generally faster compared to the JavaScript libraries commonly used before. As of June 2009 the following browsers have or will have native JSON support, via JSON.parse() and JSON.stringify():

• Mozilla Firefox 3.5+
• Microsoft Internet Explorer 8
• Opera 10.5+
• Webkit-based browsers (e.g. Google Chrome, Apple Safari)

At least 5 popular JavaScript libraries have committed to use native JSON if available:

• YUI Library
• Prototype
• jQuery
• Dojo Toolkit
• mootools

Comparison with other formats

JSON is promoted as a low-overhead alternative to XML as both of these formats have widespread support for creation, reading and decoding in the real-world situations where they are commonly used. Apart from XML, examples could include OGDL, YAML and CSV. Also, Google Protocol Buffers can fill this role, although it is not a data interchange language.

XML

XML can be used to describe structured data and to serialize objects. Various XML-based protocols exist to represent the same kind of data structures as JSON for the same kind of data interchange purposes. When data is encoded in XML, the result is typically larger in size than an equivalent encoding in JSON, mainly because of XML's closing tags, but if the data is compressed using an algorithm like gzip there is little difference because compression is good at saving space when a pattern is repeated. There are alternative ways to encode the same information. Both of the following XML examples carry the same information as the JSON example above in different ways.

<person>
  <firstName>John</firstName>
  <lastName>Smith</lastName>
  <age>25</age>
  <address>
    <streetAddress>21 2nd Street</streetAddress>
    <city>New York</city>
    <state>NY</state>
    <postalCode>10021</postalCode>
  </address>
  <phoneNumber type="home">212 555-1234</phoneNumber>
  <phoneNumber type="fax">646 555-4567</phoneNumber>
</person>

<person firstName="John" lastName="Smith" age="25">
  <address streetAddress="21 2nd Street" city="New York" state="NY" postalCode="10021" />
  <phoneNumber type="home" number="212 555-1234"/>
  <phoneNumber type="fax"  number="646 555-4567"/>
</person>

The XML encoding may therefore be shorter than the equivalent JSON encoding. A wide range of XML processing technologies exist, from the Document Object Model to XPath and XSLT. XML can also be styled for immediate display using CSS. XHTML is a form of XML so that elements can be passed in this form ready for direct insertion into webpages using client-side scripting.

Efficiency

JSON is used primarily for communicating data over the Internet, but has certain inherent characteristics that may limit its efficiency for this purpose. Most of the limitations are general limitations of textual data formats and thus also apply to XML (excepting binary XML) and YAML. For example, despite typically being generated by an algorithm (by machine), parsing must be accomplished on a character-by-character basis. Additionally, the standard has no provision for data compression, interning of strings, or object references. Compression can, of course, be applied to the JSON formatted data (but the decompressed output typically still requires further full parsing for recognizable keywords, tags and delimiters).

Object references

The JSON standard does not support object references, but the Dojo Toolkit illustrates how conventions can be adopted to support such references using standard JSON. Specifically, the dojox.json.ref module provides support for several forms of referencing including circular, multiple, inter-message, and lazy referencing.

See also

• JSONP – JSON with Padding, a pattern of usage commonly employed when retrieving JSON from a webpage
• BSON – binary JSON
• GeoJSON
• JSON-RPC
• SOAPjr – a hybrid of SOAP and JR (JSON-RPC)
• JsonML
• Comparison of data serialization formats

External links

• Format home page
• RFC 4627 - The application/json Media Type for JavaScript Object Notation (JSON)
• JSON-Introduction By Microsoft
• JSON Schema Proposal
• Limitations of JSON