What happened to application/json in WCF DS 5.0?


The roadmap for serialization formats

We have been talking for a while about a more efficient format for JSON serialization. The new serialization format will be part of the OData v3 protocol, and we believe that the much-improved JSON format should be the default response when requesting application/json.

You may notice that when you upgrade to WCF DS 5.0, requesting the old JSON format is a bit different. To get the old JSON format, you must now explicitly request application/json;odata=verbose or set the MaxDataServiceVersion header to 2.0.

When will I get a 415 response and what can I do about it?

WCF Data Services 5.0 will return a 415 in response to a request for application/json if the service configuration allows a v3 response and if the client does not specify a MaxDataServiceVersion header or specifies a MaxDataServiceVersion header of 3.0. Clients should always send a value for the MaxDataServiceVersion header to ensure forward compatibility.

There are two ways to get a response formatted with JSON verbose:

1. Set the MaxDataServiceVersion header to 2.0 or less. For instance:

GET http://odata.example.org/Items?$top=5 HTTP/1.1

Host: odata.example.org

Connection: keep-alive

User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64) AppleWebKit/535.19 (KHTML, like Gecko) Chrome/18.0.1025.152 Safari/535.19

Accept: application/json

Accept-Encoding: gzip,deflate,sdch

Accept-Language: en-US,en;q=0.8

Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.3

MaxDataServiceVersion: 2.0

2. Request a content type of application/json;odata=verbose. For instance:

GET http://odata.example.org/Items?$top=5 HTTP/1.1

Host: odata.example.org

Connection: keep-alive

User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64) AppleWebKit/535.19 (KHTML, like Gecko) Chrome/18.0.1025.152 Safari/535.19

Accept: application/json;odata=verbose

Accept-Encoding: gzip,deflate,sdch

Accept-Language: en-US,en;q=0.8

Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.3

MaxDataServiceVersion: 3.0

It’s possible to modify the headers with jQuery as follows:

$.ajax(url, {

    dataType: "json", // this tells jquery that you are expcting a json object and so it will parse the data for you.

    beforeSend: function (xhr) {

        xhr.setRequestHeader("Accept", "application/json;odata=verbose");

        xhr.setRequestHeader("MaxDataServiceVersion", "3.0");

    },

    success: function (data) {

       // do something interesting with the data you get back.

    }

});

Why did WCF DS 5.0 ship before JSON light?

We had a set of features that were ready to be released as part of WCF DS 5.0. The more efficient JSON implementation is currently in progress and will be released sometime later this year.


Comments (7)

  1. Wow .NET 4.5 and friends is turning out to be a real Vista.

  2. John says:

    How does one request this using URL syntax? The following does not work:

    http://localhost:8080/CDS/Users$format=json

  3. Hi John,

    Support for the $format query option is not built into the WCF Data Services implementation of OData. There is a commonly-used sample which adds JSONP and $format support, but it needs a slight tweak to work correctly with the 5.0 release (to specify odata=verbose in the accept header).

  4. John says:

    Thanks Matt. Just out of curiosity, why is it not part of the WCF Data Services implementation? Is it not part of the OData standard?

  5. I don't really have a good answer for why $format has no built-in support.

    In general, there will always be parts of the protocol that certain implementations will not support (though we strive to keep that to a minimum for WCF DataServices). I suppose that given the existing community support, adding it would just take time away from other things (like DateTimeOffset, which was also in the protocol before the implementation).

    If its really important to you, consider adding/voting for it it over at the voting site: data.uservoice.com/…/72027-wcf-data-services-feature-suggestions

  6. Julie Lerman says:

    I have the same question as John. The JSONP extension has been around for a while. One would presume that it could have been wrapped in, but perhaps there's something about release process and schedling that prevented it. It's a really important feature. Voting!!

Skip to main content