JSON Vs. XML for Data Interchange

Published 2011-03-05 – Updated 2011-03-05

Introduction

Since the rise of the Internet as a business network, one of the primary focuses of my work has been messaging infrastructure. As a consequence, I know a good messaging data format when I see it - I have around 20 years of industry experience with communications and messaging systems, as well as extensive experience with web-based services on the back end (having written several HTTP servers in different languages).

I started out when 300 BAUD modems were still in use, 1200 BAUD modems were common and 9600 BAUD modems were state of the art. Back then, the number of bytes on the wire were critical - we dealt in protocols in which every bit was utilized to full advantage. Even when “high speed” modems between 28K and 56K were common bytes were still precious enough that when I needed a new wire protocol in the mid 90’s which had to be very flexible and extensible I designed something which was, in hindsight, essentially a highly compact binary form of XML, which represented packets as extensible objects with a primary payload and optional attributes. This was before I had been exposed to either SGML or HTML (XML, of course came some time later).

Two caveats are in order. First, to be clear, I am not commenting on XML as a document markup format, for which purpose it is well suited. Second, I routinely omit the quotes on JSON keywords - even though the spec requires them, good parsers allow them to be omitted. JSON is far more readable without them and unless they are needed (due to spaces or restricted characters being part of the keyword or use of reserved words in JavaScript), they simply add noise. A better alternative is to just begin each keyword with an uppercase character and use only mixed case Letters and digits.

Reasons to Prefer JSON back to top

JSON syntax is simple and succinct. The entire specification is presented in a single web page, most of which consists of 5 diagrams. The syntax is entirely described in a side-bar on that page. The JSON high-level structures are simply Object, Array and Value. Compare that to the 5th edition XML specification.

JSON syntax is regular, and is therefore simple to parse. A functionally rich parser can be written using Java in about 700 well-formatted lines (excluding JavaDoc comments).

JSON representation is relatively compact. In our example below the JSON is 244 characters to XML’s 320, which is 76% of the size of the XML. And dropping the keyword quotes brings the JSON down to 226 characters.

JSON is inherently more legible and has the flexibility to be extremely legible, as our examples show. JSON is, therefore, easier to maintain by hand with no more sophisticated tool than a text editor.

JSON is less error-prone. Twice while typing up the examples below I accidentally omitted a ‘/’ from a closing tag, but it was not at all obvious on review that I had done so (and the parser could not actually detect a fault until it reached the container’s closing tag).

JSON does not have the confusing and holy-war-inducing differentiation between attributes and elements and doesn’t need them since a JSON value is as succinct as an XML attribute.

JSON fits the common intuitive form for describing data values: name=value.

Examples back to top

For reference, consider the follow “contact” record shown in both JSON and XML (first laid out for maximum clarity, then for maximum brevity).

XML:

<Contact>
    <Name>Joe Someone</Name>
    <Address>1 Nowhere Ave</Address>
    <Address>Apt 15</Address>
    <City>New York</City>
    <State>New York</State>
    <Zip>10292</Zip>
    <Phone>212-111-1111</Phone>
    <Phone>212-222-2222</Phone>
    <Phone>212-111-1111</Phone>
    <Email>Joe.Someone@nowhere.com</Email>
    <WebSite>http://nowhere.com/Joe</WebSite>
</Contact>

<Contact><Name>Joe Someone</Name><Address>1 Nowhere Ave</Address><Address>Apt 15</Address><City>New York</City><State>New York</State><Zip>10292</Zip><Phone>212-111-1111</Phone><Phone>212-222-2222</Phone><Phone>212-111-1111</Phone><Email>Joe.Someone@nowhere.com</Email><WebSite>http://nowhere.com/Joe</WebSite></Contact>

JSON:

"Contact": {
  "Name"    : "Joe Someone",
  "Address" : [ "1 Nowhere Ave", "Apt 15" ],
  "City"    : "New York",
  "State"   : "New York",
  "Zip"     : "10292",
  "Phone"   : [ "212-111-1111", "212-222-2222", "212-333-3333" ],
  "Email"   : "Joe.Someone@nowhere.com",
  "WebSite" : "http://nowhere.com/Joe"
  }

"Contact":{"Name":"Joe Someone","Address":["1 Nowhere Ave","Apt 15"],"City":"New York","State":"New York","Zip":"10292","Phone":["212-111-1111","212-222-2222","212-333-3333"],"Email":"Joe.Someone@nowhere.com","WebSite":"http://nowhere.com/Joe"}

Better JSON:

Here I’ve made a couple of alterations, which my parser is specifically coded to accept - dropped the quotes on the keywords which greatly improves readability, and dropped trailing commas on lines, accepting EOL as equivalent to a comma.

Contact: {
  Name    : "Joe Someone"
  Address : [ "1 Nowhere Ave", "Apt 15" ]
  City    : "New York"
  State   : "New York"
  Zip     : "10292"
  Phone   : [ "212-111-1111", "212-222-2222", "212-333-3333" ]
  Email   : "Joe.Someone@nowhere.com"
  WebSite : "http://nowhere.com/Joe"
  }

Contact:{Name:"Joe Someone",Address:["1 Nowhere Ave","Apt 15"],City:"New York",State:"New York",Zip:"10292",Phone:["212-111-1111","212-222-2222","212-333-3333"],Email:"Joe.Someone@nowhere.com",WebSite:"http://nowhere.com/Joe"}

Code Craft

Software is equal parts Art, Craft, and Engineering