There’s been some confusing back and forth lately about ASP.NET Web API and JSON. During the time between the last WCF Web API preview and the current ASP.NET Web API beta, it’s clear that effort has gone into smoothing out some of DataContractJsonSerializer’s (DCJS) quirks. However, while things like DateTime and Enum deserialization have been improved, issues have still persisted with Anonymous Types, Dictionaries, and DateTime serialization.

Unfortunately, the underlying cause of those remaining issues was too fundamental to simply spackle over. One of the most frustrating aspects of DCJS is that it’s rooted in WCF’s mindset that all things can be expressed as XML and then translated to other formats. In that world, data like Anonymous Types and simple collections of key/value pairs are uninteresting oddities. So, as long as ASP.NET Web API is saddled with DCJS, it’s at a disadvantage in scenarios requiring more flexible JSON serialization.

DataContractJsonSerializer: No one likes you!

Getting away from DCJS is such an obvious first step when using Web API that Microsoft’s own Henrik Nielsen[0] published a guide to switching from using DCJS to using James Newton-King‘s Json.NET last month. This week, Rick Strahl wrote a similar post on how to use JavaScriptSerializer or Json.NET with Web API.

In the same vein, Scott Hanselman had a good post about the woes of dealing with dates in JSON last week. Dates in JSON are bad enough already[1], but the existing JSON serializers built into .NET make them even worse if you’re not using MicrosoftAjax.js or a compatibility wrapper of some sort. His solution was to use Henrik’s approach for jettisoning DCJS and switching to using Json.NET (which supports the de facto standard ISO date format).

In that post, Scott casually mentioned some relatively huge news: Json.NET will be included as the default JSON serializer in Web API by the time it’s released.

Just so we’re clear

It seems like the message about Json.NET becoming the default JSON serializer in Web API got muddled a bit, hiding in the middle of Scott’s post. So, I wanted to hone in on that specifically and hopefully add some clarity.

In fact, I double-checked with Scott Hunter[2] first to be sure I wasn’t adding to the confusion myself. Here’s what he had to say:

We are making the default moving forward.

It doesn’t get more definitive than that.

This is a good thing

Many of us have been trending toward using ASP.NET as a JSON-speaking backend to power client-side JavaScript as much as anything else lately. For that purpose, this is fantastic news that resolves the last few serialization issues that Web API had as compared to current approaches using JavaScriptSerializer.

It may seem troubling that the default DateTime serialization is changing, but the short-term inconvenience of dealing with that will be well worthwhile in the long run. Moves like this that make ASP.NET more flexible and interoperable with other platforms are ultimately a boon for us all.

Further, isn’t it great to see Microsoft embracing and leveraging an open source project in the community instead of reinventing that wheel again? In my mind, this is one of the best examples of Microsoft playing nice with an open source project since they adopted jQuery in 2008.


[0]: It must be nice to just use a Wikipedia link as your Twitter bio.

[1]: Dates in JSON are such a disaster that I was even able to ride their coattails to a miniature round of applause during Crockford’s talk at MIX11 (at the end, in the Q&A). You know it’s serious business when I’m the only person other than Crockford to get applause during a Crockford talk!

[2]: Scott is Principal Program Manager Lead on the ASP.NET team. You should follow him if you’re an ASP.NET developer on Twitter.