JSON returned from listdata.svc for a full list, but "XML" for a single item

I've been trying to use jQuery to get some data from a SharePoint list named Articles, using REST.  Hit a wall, couldn't figure it out.  Quick blog post about how I got around it.

Basically, when I tried to use $.getJSON with this URL:

http://sharepoint/_vti_bin/listdata.svc/Articles()

I was able to parse the data in jQuery as you'd expect.  Worked like a dream.  However, when I tried to just return one single list item, using:

http://sharepoint/_vti_bin/listdata.svc/Articles(1)

jQuery silently failed.  Couldn't get any data out of it whatsoever.  When I looked at Google Chrome's Developer Tools (specifically, the Network function), I could see that Articles() was being returned as application/json as you'd expect, but Articles(1) was being returned as text/plain.  jQuery didn't like that.

So, I added a parameter to my URL:

http://sharepoint/_vti_bin/listdata.svc/Articles(1)?format=JSON

And everything is right in the world again.

The simple art of making Json work in Internet Explorer

A couple of projects I've been working on - both for my day job, and for my personal site - utilise ASP.NET MVC, jQuery and Json.  My prior development was using exclusively ASP.NET AJAX and, before that, plain old PHP, so when I discovered the three technologies above, I've not really understood why web development was ever any other way.

I primarily develop in Google Chrome - I used to use FireFox and Firebug, but found that Chrome's included Developer Tools are as good as - possibly better than - Firebug, particularly the Network monitor. The organisation I work in only supports Internet Explorer, but that would only affect the layout and styling, right?  Once I've got the page looking right, I wouldn't need to check the actual functionality when it comes to Json data.

I couldn't have been more wrong.  Although the site worked fine in Internet Explorer, posting data back to the database, and the updated information would even show in Chrome, IE just refused to show what had changed.  So I dusted off the F12 Developer Tools in Internet Explorer - extremely difficult to do after using Chrome's Development Tools - and started to diagnose.

The first step I took was to open the Json request in a new IE tab.  This wouldn't work.  Instead of showing the raw Json data as I'd expect, it would attempt to download a file.  I didn't want this, and for a while, thought this might be the cause of all my problems.

I did some research, and the ever-useful stackoverflow gave me the answer - I had to change every return Json command in my Controller to explicitly specify a MIME type.  I shouldn't have expected Internet Explorer to figure it out for itself, like Chrome does.  This link - IE9 JSON Data “do you want to open or save this file” - gave me the following answer:

return Json(someData, "text/html", System.Text.Encoding.UTF8,
                        JsonRequestBehavior.AllowGet);

Splendid - IE doesn't insist on downloading this file now, and will show the raw Json data instead.  But looking at the data returned, I didn't see an error that would cause the data displayed on my actual page to be out of date - I used a simple "return Json(DateTime.Now ... )" test and this showed the correct time, down to the second.

So I continued my search for a solution to my second problem, and found another post - Unexpected Caching of AJAX results in IE8 - that indicated Internet Explorer forcibly caches AJAX requests.  Although the request appears in the Network monitor, the data it uses is out of date.  Adding the following line to my jQuery code resolves everything:

$.ajaxSetup({
    cache: false
});

I'm glad I've managed to solve this issue, but I must admit, it's taken some of the fun out of developing.  Everything was going so smoothly with MVC, Json, etc., until I discovered how antiquated and difficult Internet Explorer still is to this day.  Why is it so strict with MIME types?  Why is it automatically caching dynamic data?  And, of course, why does it interpret CSS so differently to other browsers?

And I suppose the ultimate question (or answer) is, why do Microsoft have to run an advertising campaign to convince people to use a free browser that is, let's face it, still included in Windows by default?

Rant over.  Moving on.