The Move to JSON


The Move to JSON










PDF version of this report
You must have Adobe Acrobat reader to view, save, or print PDF files. The reader
is available for free
download.

The Move to JSON

by Lynn Greiner

Copyright 2017, Faulkner Information Services. All Rights Reserved.

Docid: 00021354

Publication Date: 1702

Report Type: TUTORIAL

Preview

JavaScript Object Notation,
or JSON, is an open standard for data interchange developed as an alternative to
XML. Developers are increasingly using it, along with HTML5 and JavaScript,
rather than XML, especially in mobile applications. Why? They say it’s simpler.

Report Contents:

Executive Summary

[return to top of this report]

JavaScript Object Notation,
or JSON, is an open standard for data interchange developed as an
alternative to XML. Like XML, it provides a mechanism for the exchange of
text information, but is considered less complex.

JSON is increasingly used in application programming interfaces (APIs) that
allow developers to link Web 2.0 systems. For example, developers wishing to
create third-party Twitter clients use JSON to exchange data with the service.

Description

[return to top of this report]

JavaScript Object Notation,
or JSON, is an open standard for data interchange developed as an
alternative to XML. It is based on a subset of JavaScript, vintage 1999, but
is language independent. The Internet Engineering Task Force (IETF) JSON RFC
was released in July of 2006; there has yet to be a formal standard
published, though an API spec was finalized in May 2015
,
and there are proposed standards for multiple components, the most recent of
which was released in January 2017, for object signing and encryption.

JSON provides syntax for storing and exchanging text information, much
like XML. An open standard for human readable data exchange, it uses
conventions similar to those in the C family of languages (C, C++, C#, Java,
JavaScript, Perl, Python, and many others).

JSON is smaller than XML and faster and easier to parse (and read). Its text format
is the same as that used to create JavaScript objects, so a JavaScript
program can use built-in functions to execute JSON to produce native
JavaScript objects. JSON is capable of representing numbers, booleans,
strings, null, and arrays (ordered sequences of values) and objects
(string-value mappings) composed of these values (or of other arrays and
objects). It doesn’t natively represent more complex data types like
functions, regular expressions, dates (date
objects by default serialize as a string containing the date in ISO format,
so while they don’t round-trip, the information isn’t completely lost),
and other data types. Values can be transformed as they are serialized, or
prior to deserialization, to let JSON represent those additional data
types.

JSON is most frequently used in Web applications sending data from server
to browser, typically through Ajax (dubbed Ajaj when XML is replaced by
JSON). The jQuery JavaScript library includes
methods that make it easy to receive JSON-encoded data via Ajax requests.
Because it sends relatively small amounts of data, it is considered
especially useful for mobile applications.

In the financial industry, XBRL International is
developing an XBRL-JSON spec to allow data collected and validated in XBRL to be
distributed on the Web using JSON.

Microsoft developers can take advantage of the technology through JSON.NET,
an open source framework that supports Windows 8, Windows Store, Silverlight, Windows Phone
8, .NET 2, 3.5, 4, and 4.5, and Xamarin
(now part of Visual
Studio). JSON.NET
9
.0, release

1, was released in June
2016. JSON.NET is community supported on Stack Overflow, a question and
answer site for professional developers as well as programming enthusiasts. Its
development is now run through GitHub.

Current View

[return to top of this report]

Statistics show significant growth in JSON APIs. In 2009, 191 were
registered and by August of 2010 there were already 223. In 2011, one in five
new APIs was JSON only, suggesting that developers are finding the technology a
suitable substitute for the more complicated XML. In 2013, 60 percent of new
APIs supported JSON, versus only 37 percent supporting XML. Overall, over 47
percent of APIs in the ProgrammableWeb directory now support JSON; as of January
2016, there were 20 percent more JSON APIs than those supporting XML, a number
that by February 2017 had doubled. There are now more than 3,500 JSON APIs
in the directory.

However, in a 2007 post1 on
Quoderat, scholar and open source guru David Megginson pointed out three
things that anyone in the XML vs. JSON debate needs to understand. He said:

  1. There is no information that can be represented in an XML document
    that cannot be represented in a JSON document.
  2. There is no information that can be represented in a JSON document
    that cannot be represented in an XML document.
  3. There is no information that can be represented in an XML or JSON
    document that cannot be represented by a LISP

    S-expression    .

Furthermore, he pointed out that the main differences are the size of the
user bases, software support, and syntactical convenience.

Other developers prefer JSON for client-side JavaScript use, purely as a
convenience. Once the data has been parsed and decoded, it is addressable in
standard JavaScript notation, which removes a step from the process.

Rob Zazueta of Tibco Mashery notes that JSON isn’t ideal for
everything, however. He said in a company blog post:

JSON’s biggest weakness is its lack of defined data
structures. Proponents of XML have created a series of data formats that can be
used to easily exchange and validate data across disparate systems. The
Schema.org
site, supported by several large companies including Google, Yahoo and
Microsoft, acts as a repository for many of these definitions.

JSON, however, only defines simple variables, arrays
and hashes – arrays that use strings instead of numbers as the index – and
little else. As a result, API producers have frequently developed their own JSON
response formats in the absence of well-defined standards. In the last couple of
years, some standards have begun to emerge such as HAL, Siren and JSON-LD –

which recently gained acceptance as a W3C Recommendation. But
it will be some time before the dust settles and API producers change their
responses to conform to these standards.

However Yegor Bugayenko, CTO of Teamed.io, says in his blog that XML and JSON
are different things, and one can’t entirely replace the other. He blogged:

JSON and XML are very different things with their own
areas of applicability.

JSON is a good data format.
But it’s just a data format. We’re using it temporarily
to transfer a piece of data from point A to point B. Indeed, it is shorter than
XML and more readable. That’s it. XML is not a data format; it is a
language. A very powerful one.

In March 2014, Google announced support for GeoJSON in its Google Maps API.
GeoJSON is an open source file format based on JSON, developed in 2008, that
eases visualization creation.

Another twist, JSON-stat, is a lightweight JSON format for data dissemination
based on a cube model. It is best suited for data visualization, mobile apps, or
open data initiatives.

Outlook

[return to top of this report]

Originally, usage statistics indicated that the growth in JSON had not
been at the expense of XML, but had been incremental; however, most new APIs
now support JSON rather than XML. Mobile developers prefer JSON for its lower use of
bandwidth and resources. Many Web 2.0 APIs, such as Twitter, have adopted
it as their data interchange method of choice since mapping object data to
JSON is less complex, which translates to fewer errors.

This trend is
being illustrated by the adoption of JSON by major players. Google’s
BigQuery API skipped XML altogether, going straight to JSON, and the US
Library of Congress Prints and Photographs collection can be serialized
in JSON with a simple addition of "?fo=json" to the end of an image’s URL.

In addition, a number of new security protocols and formats being developed
by the IETF, such as JavaScript Object Signing and Encryption (JOSE), now a
proposed standard RFC, rely
on JSON, as do OpenID Connect and JSON Web Token.

In October 2012,
an article in the Internet Society’s IETF Journal noted that XML is becoming
a technology that is not used in data interchange with users, but is instead used to manage
and generate content on the server. Said the author, "In other words, JSON
will not replace XML, but a lot of the structured data communications in
which XML was once the only consideration will eventually migrate to JSON."2

In his January 2014 post, Zazueta was more optimistic about JSON’s
ultimate fate, but he did offer caveats. "RESTful API’s should be
designed to be fast, reliable and easy to use. JSON is becoming
the data exchange format of choice because it aligns so well with those
goals," he said. "But, until standards shake out that allow developers to
use more generalized clients to parse JSON data and provide strict type and
format validation, XML will likely be the format of choice for API
developers most concerned about providing a rigid data structure. We may
well see the JSON standards shake out in the next year or two, which means
XML may soon be consigned the same fate as floppy disks and punch cards."3

Recommendations

[return to top of this report]

JSON is becoming a preferred technology, along with HTML5 and JavaScript, in
the construction of Web 2.0 applications. Its performance advantages and lesser
complexity make it especially ideal for mobile applications. XML is not going
away in the near future, but its usage is migrating to more internal functions rather than
client-facing. Twitter, for example, has switched its API to JSON,
and there are beginnings in the XBRL world
.

Companies relying on XML may find that it is less and less supported in
APIs, making knowledge of JSON critical for developers. Those familiar with
JavaScript should have little trouble adapting to the new syntax.

References

[return to top of this report]

About the Author

[return to top of this report]

Lynn Greiner is Vice President,
Technical Services, for a division of a multi-national corporation, and
also an award-winning computer industry journalist. She is a regular
contributor to Faulkner Information Services and a member of the
Advisory Panel.

[return to top of this report]