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. 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 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: 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: 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: 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. 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. 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: 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: 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: 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 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. 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. 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. A Data Interchange Format
A Quick Look at JSON
{
"LastName" : "Esposito",
"FirstName" : "Dino",
"Address" : {
"Street" : "Foo Street",
"StreetNo" : 123,
"City" : "New York",
"Country" : "USA"
},
"Phone-Fax" : ["123456", "123459"]
}
public class XXX
{
string LastName {get; set;};
string FirstName {get; set;};
YYY Address {get; set;};
string[] Phone-Fax { get; set; };
}
<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>
The X in AJAX
.NET Support for JSON
JavaScriptSerializer serializer = new JavaScriptSerializer();
string json = serializer.Serialize(obj);
public class Foo
{
public string ID {get; set; };
[ScriptIgnore]
public string InternalCode {get; set;}
:
}
public T Deserialize<T>(string input);
public Object DeserializeObject(string input);
The New DataContractJsonSerializer Class
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;
Conclusion
JSON and XML
Discover the New Lingua Franca of AJAX Applications
0 comments
Hide comments
