JSON and XML

Discover the New Lingua Franca of AJAX Applications

After years of pushing XML as thelingua franca of the Web, what happened with the advent of AJAX , which makes the whole Web come of age? We bluntly dropped XML in favor of JSON . And what s JSON? And how is it different from, and better than, XML? An acronym for JavaScript Object Notation, JSON is a lightweight text format for data interchange. At such a high level of abstraction, JSON is not really that different from XML. And what s the role of JavaScript ? Is JSON specific to JavaScript? 

In this article, we ll compare and contrast JSON and XML in the perspective of Web and AJAX applications. We ll also take a look at the low-level classes in the .NET Framework 3.5 used to serialize and deserialize .NET objects to JSON.

 

A Data Interchange Format

In a Web AJAX application, at some point you need to call some server-based code. In doing so, you likely need to pass some input data and wait to receive some other data. Clearly, a serialization format is required to transform platform-specific data (i.e., a .NET object) into an HTTP network packet. For years, this field has been the reign of XML. To a large extent, this is still the reign of XML, but not when a Web browser is used as the client.

In fact, JSON is the new standard format for browsers and Web servers to exchange data over HTTP when a script-led request is made. The main reasons for preferring JSON over XML can be summarized by saying that, overall, JSON is simpler than full-blown XML and gets a free deserialization engine in virtually any browser that supports JavaScript. JSON is not designed to reach the heights of complexity and portability of full XML, but it is just as sophisticated as a simple and lightweight XML limited to nodes and attributes. When used in a service-based context, JSON requires HTTP endpoints to understand the format and be able to serialize to it and deserialize from it. This requirement is common to XML when used with SOAP Web services.

 

A Quick Look at JSON

A JSON string represents the state of an object regardless of the host platform. The JSON string can describe a single object or an array of objects or scalar values. Needless to say, everything has to ultimately be a string, including Boolean and dates. Numbers, instead, have a slightly different treatment. An object takes the following form:

{

 "LastName" : "Esposito",

 "FirstName" : "Dino",

 "Address" : {

              "Street" : "Foo Street",

              "StreetNo" : 123,

              "City" : "New York",

              "Country" : "USA"

            },

 "Phone-Fax" : ["123456", "123459"]

}

The description of the object is wrapped by a pair of curly brackets {...}. Any nested object gets the same representation. Property names and string values are wrapped by quotes. Each property/value pair is separated from the next by a comma. The property and its value are separated by a colon symbol. Two types of value get a special treatment: numbers and arrays of values (including objects). A number is not rendered in quotes. An array lists its values as numbers, objects, or quoted strings and separates them using a comma. The whole array content is wrapped in a pair of square brackets.

The preceding JSON description is nearly equivalent to the following C# type:

public class XXX

{

 string LastName {get; set;};

 string FirstName {get; set;};

 YYY Address {get; set;};

 string[] Phone-Fax { get; set; };

}

As you can see, XXX and YYY refer to class names that are not specified. According to the C# 3.0 naming convention, we could say that JSON is about anonymous types. A JSON string doesn t contain any platform-specific type information. In the previous code snippet, you recognize an object with four distinct properties: two strings (FirstName and LastName), one array of strings (Phone-Fax), and a custom object. The custom object, in turn, features three string properties (Street, City, Country) and a numeric property (StreetNo).

In essence, JSON leverages the same JavaScript vision of an object. In JavaScript, in fact, any object is basically an associative array of primitive values and there s no notion of type information. How easy can it be to render JSON content to a platform and language-specific object?

This point probably represents the major strength of JSON. A JSON string is extremely easy to parse for a piece of software and, all in all, refers to common-use data structures (arrays, numbers, strings) that virtually every programming language on any platform can offer.

JSON is great at representing data that comes to you in a free form. Wasn t XML also very good at doing just this? Sure, both can be used for the task. But how effectively? Let s see how to rewrite the content shown above, but with XML:

<Person>

  <FirstName>Dino</FirstName>

  <LastName>Esposito</LastName>

  <Address>

      <Street>Foo Street</Street>

      <StreetNo>123</StreetNo>

      <City>New York</City>

      <Country>USA</Country>

  </Address>

  <Phone-Fax>123456,123459</Phone-Fax>

</Person> 

I think many of you would have used a different XML representation for the same data. This is a key point to focus on to capture the difference between JSON and XML with regard to the syntax and scope. JSON has no notion of schema and validation, which is one of the major strengths of XML. This point alone sets a key difference. XML is incomparably better than JSON when it comes to portability and interoperability. When you have to ensure dialog and communication between heterogeneous systems or modules, you need a fixed contract. Here XML shines. When you need to move data around, JSON is an effective fat-free alternative to XML.

JSON focuses on data values and is neither a document format nor a markup language. As a general-purpose serialization format, JSON is limited, as well, as it has no notion of circular references. On the other hand, more so than XML, JSON content can be eyed by humans and easily parsed by computers. JSON uses a data representation that is very close to what the JavaScript interpreter does. Parsing JSON content is relatively easy, and can be resolved using tokenizing functions available on the String object in most languages.

 

The X in AJAX

One of the creators of JSON loves to label his baby as the X in AJAX, which is quite correct. If you look at the official acronym, the X in AJAX stands for XML. However, this is not what happens in the real world. Why? The Web proposes a simplified model of interaction that may not need a rigid schema and/or validation. All that authors of AJAX Web pages need is the ability to send and receive data. Therefore, this data has to be serialized and deserialized in some way between the client and the Web server. Is a schema and a bit of type information useless or just mandatory?

Having schema information available wouldn t be a bad thing per se, but not at the cost of an XML parser written in JavaScript. If we were using XML for browser-to-server AJAX-style interaction, then any browser would receive XML from any invoked endpoint. Subsequently, the browser ought to be able to process any XML data. Is a JavaScript XML parser affordable?

Writing a full-blown XML parser in JavaScript is perhaps beyond the scope of the language. In any case, no browsers today provide this feature. At the same time, the success of AJAX is largely due to the fact that today s browsers support all required technologies. A well performing parser for the full XML syntax is not a trivial piece of code to do in JavaScript. And a simpler parser limited to just nodes and attributes would actually produce a language similar to JSON. At that point, the big difference would be the style of the brackets: angle brackets or curly brackets.

Today s browsers, instead, provide native support for a JSON deserializer. Where is it? It s the plain old JavaScript eval function. Among other things, the eval function takes a JSON string and returns a corresponding JavaScript object. This is possible because JSON uses a notation that is nearly the same as the notation internally used by JavaScript to represent objects. Put another way, it s not that eval was created to support JSON it s JSON that has been set up so JavaScript s eval function can read it. Either way, as far as browser-to-server communication is concerned, JSON is a far better option than XML. That s why JSON is ultimately the X in AJAX.

 

.NET Support for JSON

When Microsoft released the ASP.NET AJAX Extensions toolkit (before the release of the .NET Framework 3.5), they made available a managed class named JavaScriptSerializer. The class is available in the System.Web.Script.Serialization namespace. In the .NET Framework 3.5, the same class has been marked obsolete. The JavaScriptSerializer contains the method Serialize, which takes a .NET object and serializes it to JSON. The Deserialize method, instead, does the reverse, and from a JSON string builds up a .NET object. Serializing a class is straightforward:

JavaScriptSerializer serializer = new JavaScriptSerializer();

string json = serializer.Serialize(obj); 

The class supports several standard types, including string, dates, Boolean, numbers, GUID, array, collection, and Uri. In addition, any custom types that have public properties or fields are treated automatically. You can use the ScriptIgnore attribute to indicate that a given public property on a class doesn t have to be persisted to JSON:

public class Foo

{

   public string ID {get; set; };

    [ScriptIgnore]

   public string InternalCode {get; set;}

   :

}

When it comes to deserializing, what about type information? The eval function in JavaScript simply needs to return an associative array. But in .NET? For this reason, the JavaScriptSerializer class always adds a special metadata property named __type. This property contains the name of the real type being serialized. The Deserialize method uses that information to instantiate the proper class. There are two flavors of a deserializer:

public T Deserialize<T>(string input);

public Object DeserializeObject(string input); 

The former deserializes the provided string to an object of type T. The latter simply deserializes to an object graph. In this regard, JavaScriptSerializer also supports anonymous types and is really easy to use. As mentioned, this class has been marked obsolete in the .NET Framework 3.5 and a new replacement class was provided.

 

The New DataContractJsonSerializer Class

The new JSON serializer is the class DataContractJsonSerializer defined in the namespace System.Runtime.Serialization.Json living in the System.ServiceModel.Web assembly. The class performs the same tasks as JavaScriptSerializer, but with a different syntax. To deserialize, proceed as shown in Figure 1.

DataContractJsonSerializer ser = new DataContractJsonSerializer(typeof(Product));

string json = @"{""FirstName"" : ""Dino"", ""LastName"" : ""Esposito""}";

MemoryStream ms = new MemoryStream(Encoding.Unicode.GetBytes(json)); 

Product product = ser.ReadObject(fs) as Product; 

Figure 1: DataContractJsonSerializer doesn t support other forms of deserialization.

As you can see, the target type has to be indicated explicitly. The DataContractJsonSerializer doesn t support other forms of deserialization. You use the WriteObject method to serialize. Both methods require a stream to operate.

 

Conclusion

For AJAX applications, JSON is a better fit than XML as a data interchange format. JSON is text-based, but considerably simpler than XML because it produces smaller footprints and is easier to process for humans and computers. But JSON is not a full replacement for XML. Wherever schema and validation are essential (interoperability between platforms and modules), XML remains largely superior. But for the AJAX-powered Web, XML is overkill, and would require a new version of the browser.

To further prove this concept, consider what is happening with Silverlight 2. Although Silverlight 2 supports the DataContractJsonSerializer class, its wrapper for Web and WCF services doesn t use JSON internally. This is a complete turnaround from ASP.NET AJAX. The reason? In Silverlight, having an XML parser that does SOAP processing doesn t pose any performance or deployment issues. Subsequently, why should we drop schema, validation, and the other beautiful features of XML? And if you want only JSON, you can manually use the DataContractJsonSerializer class.

Hide comments

Comments

  • Allowed HTML tags: <em> <strong> <blockquote> <br> <p>

Plain text

  • No HTML tags allowed.
  • Web page addresses and e-mail addresses turn into links automatically.
  • Lines and paragraphs break automatically.
Publish