jQuery, ASP.NET Web API, and Json.NET walk into a bar…
ASP.NET By Dave Ward. Posted March 13, 2012There’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 Json.net 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.
Footnotes
[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.
Similar posts
- Using jQuery to Consume ASP.NET JSON Web Services
- ASP.NET web services mistake: manual JSON serialization
- ASMX and JSON – Common mistakes and misconceptions
- Improving jQuery’s JSON performance and security
- ASMX ScriptService mistake – Invalid JSON primitive
One Mention Elsewhere
- Force WebAPI to return JSON by Default for Html GET Requests - Ellis Web Development
5 Comments
You made me laugh with “DataContractJsonSerializer: No one likes you!”. So very true.
I’m really, really glad to see JSON.net becoming the default.
I ask forgiveness for what I’m about to say next…
… and the bartender says, “Why the LongDate?”
I think anybody who has ever had to use any of the DataContract*Serializer disasters classes are grateful that we can replace these components in Web API. A lot of these things are fairily easy to replace, Servicestack.Text Media Type Formatter and with the various contrib projects, WCF Web API Contrib, Thinktecture.Web.Http and WebAPIContrib gives the community an oppurtunity to help itself out as well as tell Microsoft the things that need to be worked on in following versions.
Did you know that RIA/JS has been “renamed” to Upshot?
This was a very interesting information for me to sort all that new stuff in my brain.
I think they´re working on a really, really awesome stack there.
JSON.Net :)
yeah, this made me happy :)
Is there a similar approach for a default / RESTful WCF-Service?
Further, isn’t it great to see Microsoft embracing and leveraging an open source project in the community instead of reinventing that wheel again?
I think Microsoft is finally starting to realize that the “internet world” doesn’t revolve around them. And developers will happily (or less reluctantly) use an open source tool or framework to avoid their “not invented here” mentality.
I agree with you, it is nice. I prefer their toolchain over anything else out there. JSON.Net is a big win for us all.
Leave a Reply
Basic HTML is allowed (e.g. <a>, <blockquote>, <strong>, <em>, etc).
To post formatted code blocks, use <pre lang="x">code</pre>, where x is asp, csharp, html, javascript, or xml.
What do you think?
I appreciate all of your comments, but please try to stay on topic. If you have a question unrelated to this post, I recommend posting on the ASP.NET forums or Stack Overflow instead.
If you're replying to another comment, use the threading feature by clicking "Reply to this comment" before submitting your own.