Microsoft MVP Logo

Recently I was working on a project where I had to work with someone else's code... and isn't that always a ton of fun! At any rate, the other developer had done something that I find to be quite challenging to not only code, but even harder to consume. From my point of view, it usually stems from a case of not knowing a better way, hence the point of my post.

These days so much stuff we do involves calling services either from client-side or server-side solutions. More and more of these services are REST based that can return either XML or JSON formatted data. Most people always use JSON when working client-side, but when working with strongly typed languages like those in the .NET Framework, developers still seem to focus on processing XML server-side.

Let's focus on just the server-side story. I'm going to use the SharePoint REST API in my example here's some typical C# code that you'd write to get a list of items back from a task list in SharePoint:

If you can't see the code snippet above, check this post out on my blog because I'm hosting my code snippets in GitHub Gists that are displayed using script tags that may not render in your blog reader.

Personally I find XML hard and cumbersome to read. But even worse, when you want to program and process the response (much less submit the data for creating or updating entities to a REST service), you typically use LINQ to XML... you know all those XDocument and XElement classes. But that's not the worst part... how about dealing with all those darn namespaces!

Check this code out... this is taking the response gathered from the string in the code above and extracting the results:

That code just looks clunky to me and a bit too much brute force. Thankfully there's another option! For me, I'll take a JSON response and do some direct serialization & deserialization.

How does this work? What you do is create a strongly typed object that matches the response you get back from the service. For instance, here's the one I created:

I'll come back to this in a moment, for now let's see how it's used. Instead of using XML to process the response, let's use the popular JSON.NET library to do the same thing:

Neat? Look the hardest part of this is generating the typed version of JSON. Thankfully Visual Studio in combination with the free VS extension Web Essentials it's easy. Just copy the JSON that comes back from the service to the clipboard. Then create a blank code file and pick the Edit » Paste Special menu to find an option that pastes JSON as code! I did a bit of tweaking to mine above to do a few things:

  • By default you get a rootobject class... I usually tweak this to have two root object references, one with the Collection and one with the Single suffix for when you get one or multiple responses.
  • I use the JsonProperty attribute to rename the public class or property so I can use it in my code the way I like, but specify how it will be represented in the JSON response.

You may wonder "yeah, but should a trust some open source library like JSON.NET?" Sure... you absolutely should. Why? Because a lot of commercial libraries offered by Microsoft actually use JSON.NET over the included JavaScriptSerializer. Even the new Office 365 Discovery service's SDK NuGet package depends on it: Microsoft.Office365.Directory.

Happy coding...

Comments powered by Disqus