Building the City Cloud part 2: WCF Data Services and JSON

When we developed our OData web service we came accross a situation in which we needed our webservice to return JSON in stead of XML. According to the specification OData supports both JSON and XML by including the $format query option. Unfortunately WCF Data Service does not support the $format query option and will return the following error when this query option is provided:

<error xmlns="http://schemas.microsoft.com/ado/2007/08/dataservices/metadata">
    <code /> 
    <message xml:lang="en-US">
        The query parameter '$format' begins with a system-reserved 
        '$' character but is not recognized.

The service tells you that it indeed saw the $format query option but that it didn't recognize it as a valid query option. In this blog post I'm going to show you the different options you have for resolving this little problem.


JSON stands for JavaScipt Object Notation and is used to interchange data. It is an alternative to XML and became very popular because of its simplicity and the fact that it is very lightweight, easy readable and supported on almost all platforms. It was originally derived from JavaScript, but it is a language independent technology. It especially works pretty fine with JavaScript, because in JavaScript there is no extra parser needed. JSON is primarily used to exchange data between webservices and webapplications.

Enable support for the $format query option

Although WCF Data Service does not support the $format query option it actually supports JSON as an output format. All you need to do is specify "application/json" in the Accept header of your request, but sometimes it is not easy to modify the request headers and sometimes you just want to built an OData compliant data service that supports the $format query option. The basic solution to this problem comes down to removing the $format query option and changing the Accept header to application/json.

You don''t have to do this all by yourself. There are two pieces of code out there that do the job for you:

Both of these pieces of code comes with the nice advantage that they also add support for JSONP callbacks. JSONP is a technique commonly used to circumvent the same origin policy of modern browsers. The same origin policy prevents scripts running on domain1.com to communicate with domain2.com.


Using the DataServicesJSONP library is very simple. You just need to add the JSONPSupportBehaviour to your data service definition, just like in the picture below and you have full support for JSON and JSONP in your OData web service.

 WCF Data Services Toolkit

Using the WCF Data Services Toolkit not only gives you support for JSON and JSONP, but also adds caching capabilities and offers solutions for a lot different data sources. To use the toolkit in your data service, simply inherit your service from ODataService instead of DataService, just like in the picture below and you have full support for JSON and JSONP in your OData web service.

I created a solution that contains examples of both techniques. You can download it here. The solution contains two wcf services, one that uses DataServicesJSONP and one that uses the toolkit. To compile the code you need to have SQL Compact Edition 4.0 installed. You can install it via the Web Platform Installer or directly via the Microsoft Download Center.

Did you like this? Share it:
Tagged as: , , Leave a comment
Comments (1) Trackbacks (0)
  1. It’s much easier to unedrstand when you put it that way!

Leave a comment

No trackbacks yet.