What is JSON?
- JSON stands for JavaScript Object Notation
- JSON is a lightweight data-interchange format
- JSON is plain text written in JavaScript object notation
- JSON is used to send data between computers
- JSON is language independent
- The JSON syntax is derived from JavaScript object notation, but the JSON format is text only.
- Code for reading and generating JSON exists in many programming languages.
- The JSON format was originally specified by Douglas Crockford.
Why Use JSON?
The JSON format is syntactically similar to the code for creating JavaScript objects.
Because of this, a JavaScript program can easily convert JSON data into JavaScript objects.
Since the format is text only, JSON data can easily be sent between computers, and used by any programming language.
- JavaScript has a built in function for converting JSON strings into JavaScript objects:
JSON.parse()
- JavaScript also has a built in function for converting an object into a JSON string:
JSON.stringify()
- You can receive pure text from a server and use it as a JavaScript object.
- You can send a JavaScript object to a server in pure text format.
- You can work with data as JavaScript objects, with no complicated parsing and translations.
JSON example
Here's an example of data encoded in JSON:
The structure above clearly defines some attributes of a person. It includes a first and last name, the number of times the person has logged in, whether this person is a writer, a list of companies the person works with, and a list of the personâs pets (only one, in this case). A structure like the one above may be passed from a server to a web browser or a mobile application, which will then perform some action such as displaying the data or saving it for later reference.
JSON is a generic data format with a minimal number of value types: strings, numbers, booleans, lists, objects, and null. Although the notation is a subset of JavaScript, these types are represented in all common programming languages, making JSON a good candidate to transmit data across language gaps.
Why should I use JSON?
To understand the usefulness and importance of JSON, we'll have to understand a bit about the history of interactivity on the web.
In the early 2000s, interactivity on the web began to transform. At the time, the browser served mainly as a dumb client to display information, and the server did all of the hard work to prepare the content for display. When a user clicked on a link or a button in the browser, a request would be sent to the server, the server would prepare the information needed as HTML, and the browser would render the HTML as a new page. This pattern was sluggish and inefficient, requiring the browser to re-render everything on the page even if only a section of the page had changed.
Because full-page reloads were costly, web developers looked to newer technologies to improve the overall user experience. Meanwhile, the capability of making web requests in the background while a page was being shown, which had recently been introduced in Internet Explorer 5, was proving to be a viable approach to loading data incrementally for display. Instead of reloading the entire contents of the page, clicking the refresh button would trigger a web request that would load in the background. When the contents were loaded, the data could be manipulated, saved, and displayed on the page using JavaScript, the universal programming language in browsers.
REST vs. SOAP: The JSON connection
Originally, this data was transferred in XML format (see below for an example) using a messaging protocol called SOAP (Simple Object Access Protocol). But XML was verbose and difficult to manage in JavaScript. JavaScript already had objects, which are a way of expressing data within the language, so Douglas Crockford took a subset of that expression as a specification for a new data interchange format and dubbed it JSON. JSON was much easier for people to read and for browsers to parse.
Over the course of the '00s, another Web services technology, called Representational State Transfer, or REST, began to overtake SOAP for the purpose of transferring data. One of the big advantages of programming using REST APIs is that you can use multiple data formats, not just XML, but JSON and HTML as well. As web developers came to prefer JSON over XML, so too did they come to favor REST over SOAP. As Kostyantyn Kharchenko says: "In many ways, the success of REST is due to the JSON format because of its easy use on various platforms."
Today, JSON is the de-facto standard for exchanging data between web and mobile clients and back-end services.
JSON vs. XML
As noted above, the main alternative to JSON is XML. However, XML is becoming less and less common in new systems, and it's easy to see why. Below is a version of the data you saw above, this time in XML:
<?xml version="1.0"?>
<person>
<first_name>Jonathan</first_name>
<last_name>Freeman</last_name>
<login_count>4</login_count>
<is_writer>true</is_writer>
<works_with_entities>
<works_with>Spantree Technology Group</works_with>
<works_with>InfoWorld</works_with>
</works_with_entities>
<pets>
<pet>
<name>Lilly</name>
<type>Raccoon</type>
</pet>
</pets>
</person>
In addition to being more verbose (exactly twice as verbose in this case), XML also introduces some ambiguity when parsing into a JavaScript-friendly data structure. Converting XML to a JavaScript object can take from tens to hundreds of lines of code and ultimately requires customization based on the specific object being parsed. Converting JSON to a JavaScript object takes one line of code and doesn't require any prior knowledge about the object being parsed.
Limitations of JSON
Although JSON is a relatively concise, flexible data format that is easy to work with in many programming languages, there are some drawbacks to the format. Here are the five main limitations:
- No schema. On the one hand, that means you have total flexibility to represent the data in any way you want. On the other, it means you could accidentally create misshapen data very easily.
- Only one number type: the IEEE-754 double-precision floating-point format. That's quite a mouthful, but it simply means that you cannot take advantage of the diverse and nuanced number types available in many programming languages.
- No date type. This omission means developers must resort to using string representations of dates, leading to formatting discrepancies, or must represent dates in the form of milliseconds since the epoch (January 1, 1970).
- No comments. This makes it impossible to annotate fields inline, requiring additional documentation and increasing the likelihood of misunderstanding.
- Verbosity. While JSON is less verbose than XML, it isn't the most concise data interchange format. For high-volume or special-purpose services, you'll want to use more efficient data formats.
When should I use JSON?
If you're writing software that communicates with a browser or native mobile application, you should use JSON as the data format. Using a format like XML is an out-of-date choice and a red flag to front-end and mobile talent you'd otherwise like to attract.
In the case of server-to-server communication, you might be better off using a serialization framework like Apache Avro or Apache Thrift. JSON isn't a bad choice here, and still might be exactly what you need, but the answer isn't as clear as for web and mobile communication.
If you're using NoSQL databases, you're pretty much stuck with whatever the database gives you. In relational databases that support JSON as a type, a good rule of thumb is to use it as little as possible. Relational databases have been tuned for structured data that fits a particular schema. While most now support more flexible data in the form of JSON, you can expect a performance hit when querying for properties within those JSON objects.
JSON is the ubiquitous, de facto format for sending data between web servers and browsers and mobile applications. Its simple design and flexibility make it easy to read and understand, and in most cases, easy to manipulate in the programming language of your choice. The lack of a strict schema enables flexibility of the format, but that flexibility sometimes makes it difficult to ensure that you're reading and writing JSON properly.
