The Rise Of JSONMay 17, 2011 By Karsten Januszewski
I’ve been prototyping a new service, sketching out the different pieces: payload protocol, storage, data model, transport, client/server communication, etc. And, upon completion of the prototype, I stepped back and looked at the decisions made. For example, how are we storing the data? Raw JSON. How are we serving data? As JSON.
It suddenly struck me: there was never even a question of what format we would serialize to; JSON was assumed. And the idea that we would support XML as well as JSON wasn’t even considered.
The fact that this architecture was almost assumed instead of deliberated upon got me thinking: when was it that JSON won? After all, the format isn’t that old. But its rise has been quick and triumphant. I’m not the first one to observe this of course. There’s a great piece called “The Stealthy Ascendency of JSON” on DevCentral which does some digging across a range of available web APIs, discovering an increase in the percentage of APIs that support JSON as compared to XML in the last year. The ProgrammableWeb has a piece called “JSON Continues its Winning Streak Over XML“ which similarly documents this trend. And there is also the much blogged about facts that Twitter has removed XML support from their streaming API and Foursquare’s v2 API only supports JSON.
JSON’s untyped nature flows with how the web itself works. The web does not seem like typing; it doesn’t like schemas; it doesn’t like things to be rigid or too structured. Just look at the failure of XHTML. A beautiful idea for the purists, but for the web, its lack of adoption underscores its platonic ideals.
Not to dismiss XML. It turns out, XML works fantastically well with strongly typed languages. Perhaps XML’s crowning glory these days is how it maps to object graphs — elements as objects, attributes as properties — for the purposes of creating client user interfaces. Consider mobile development. Look at both Android development (Java/XML) and Windows Phone development (.NET/XAML). Both models extensively use XML to represent user interface which map directly to an object graph. And both models use this XML representation to facilitate WYSIWYG editors like one finds in Expression Blend, Visual Studio and Eclipse. I wrote about this a fair amount quite a while ago in a paper called The New Iteration about designer/developer workflow with XAML.
Where you find an impedance mismatch is using a loosely typed payload format like JSON with a strongly typed language. This happens all the time on the server, especially if you are a .NET developer. Historically, this has caused plenty of headaches. I know I’ve spent too much time dealing with serialization/deserialization issues on the server when parsing JSON.
Well, I’m happy to say that this mismatch seems to have finally gone away with the dynamic keyword in .NET 4 combined with some great open source work by the WCF team that has resulted in a library called Microsoft.Runtime.Serialization.Json.
Consider the following c# code, which downloads my Foursquare profile:
WebClient webClient = new WebClient(); dynamic result = JsonValue.Parse(webClient.DownloadString("https://api.foursquare.com/v2/users/self?oauth_token=XXXXXXX")); Console.WriteLine(result.response.user.firstName);
Notice how the parsing of the JSON returns an object graph that I can drill into. So elegant! If you want to learn more about these new APIs, check out this post called JSON and .NET Nirvana Hath Arrived.
It’s great to see this marriage between JSON and .NET, because it’s clear JSON isn’t going away any time soon.