Leveraging OData end-points in JSON format with JQuery

So I’ve been screwing around with JQuery all weekend in an attempt to make the dynamic-control creation that I have going on in my Silverlight prototype… work without Silverlight!

I’ve been looking for a good way to leverage the Entity-Framework model that I already have in-place so I don’t have to dream up an entire new way of piping my .NET data over to Javascript. It turns out that using WCF Data Services works awesome! (I haven’t tried using EF RIA Services yet, but I bet it will work awesome too.)

Basically, if you want to get data from the O-Data endpoints that both “WCF Data Services” and “EF RIA Services” expose from your E.F. data-model, you simply need to override some of the defaults of the JQuery AJAX() method. Since I wanted my data to be returned in JSON format, and not in ATOM RSS Feed format, I modified the “dataType” parameter of the JQuery AJAX() method as follows :

The section in the Javascript that’s cool is inside the registered event handler (looks like an anonymous method… doesn’t it?) for the btnTest2 ‘onClick’ event. There, I use the ‘$’ JQuery object to get a handle on the ‘.ajax’ method. I then pass a JSON data element into the ‘.ajax’ method using directions I found on this website here. http://api.jquery.com/jQuery.ajax/

The really important aspect is that I’m setting the ‘dataType’ parameter to ‘json’. What’s really COOL about how Microsoft implemented their OData-capable WCF data extensions (WCF Data Services & EF RIA Services) is that they enabled the caller to switch between XML ATOM formatted data and JSON formatted data out-of-the-box!

I had previously looked up a way to do JSON formatted data using the URL that’s passed to the OData endpoint exposed by .NET, but then I quickly realized with JQuery, I could control the HTTP ‘Accept’ header information manually by setting the data-type, and therefore elliminate the need for the URL query-string parameter. However, if your interested in how I used a Query-String parameter to change the return data-type for a WCF Data Service from standard ATOM XML to JSON, check out this article for grins. http://code.msdn.microsoft.com/DataServicesJSONP

You may also notice that the URL I passed into the ‘.ajax’ method looks a little strange. ‘WcfDataService.svc/GenericQuestions?$filter=(GenericQuestionId eq 5)’. This is how you perform a WHERE filter on a data-table using the OData endpoints exposed in a facade layer between your Entity Framework model and the browser client. In this case, ‘GenericQuestions’ is one of my Entity names. (It represents a table in the database called ‘GenericQuestion’.) The $filter parameter is how you apply a ‘WHERE’ filter on the table. Here, I’m looking for where the primary key of the table (GenericQuestionId) equals ’5′.

6 Responses to Leveraging OData end-points in JSON format with JQuery

A powerful share, I simply given this onto a colleague who was doing a little analysis on this. And he actually purchased me breakfast because I found it for him.. smile. So let me reword that: Thnx for the treat! But yeah Thnkx for spending the time to debate this, I really feel strongly about it and love reading extra on this topic. If potential, as you change into expertise, would you thoughts updating your blog with extra particulars? It is extremely helpful for me. Huge thumb up for this weblog publish!

Yes. I’ve actually switched over to leveraging OData endpoints as they are published with RIA Services. That being said, both ways are valid… and the WCF Data Services approach defined here does a better job helping the client-code determine where to find the related data-entities.

Hello, Neat post. There is a problem with your website in internet explorer, may check this? IE nonetheless is the marketplace leader and a good component of people will pass over your fantastic writing due to this problem.

We’re a gaggle of volunteers and opening a brand new scheme in our community. Your web site provided us with useful info to work on. You have performed an impressive process and our entire group will likely be grateful to you.

These methods are vital to our work:

About CodeSmart, Inc.

CodeSmart has been locally owned and operated in the Olympia, WA area since 2002. We direct, design, develop and deliver full end-to-end information systems using leading edge Microsoft .Net technologies and recommended best practices.