This project is read-only.
Announcement: WCF Web API is now ASP.NET Web API! ASP.NET Web API released with ASP.NET MVC 4 Beta. The WCF Web API and WCF support for jQuery content on this site wll removed by the end of 2012.

Download WCF Support for jQuery (now ASP.NET Web ASP)

ClientServerDiagram.PNG In today's web it is common to build web pages with interactive elements that load data asynchronously, whether it is to pre-validate a form submission, edit some tabular data on the server, or chat with another user on the page. Commonly this is accomplished using JavaScript or a particular JavaScript client library such as jQuery talking to a backing web service. This project enables you to build these types of services using the Windows Communication Foundation (WCF) and WCF RIA Services as your services framework. We aim to provide a productive and feature-rich end-to-end experience for talking to HTTP services from JavaScript and jQuery in particular.

Depending on the type of jQuery app you're building, WCF provides an easy way to build a service to supply data to it. Suppose your application is a forms-over-data app or any other collection-based app. In this case you have some data in a database on the server and your app aims to expose that data in a grid or some other control. WCF DomainService is perfect here with its support for client or server-side querying, client-side data change events and change tracking through the $.dataSource plugin, client and server-side validation, as well as server-side support for Entity Data Model.

If your app does not fit into that shape (in other words you are building a more general-purpose app), you can drop down and take control of your $.ajax requests. In this case you would use a regular WCF Service, which gives you fine-grained control over data formats, the URI structure, exact service operations, and so on.


Next to each scenario, you will find our assessment of how feature complete is the scenario implementation.

1. Data-driven application working with a collection of entities (RIA/JS) In Progress
Another very common scenario is managing a collection of objects, in a pattern many call forms over data. The user can perform CRUD operations on the entities in the collection using a list or grid view combined with a form on the client side. Changes are aggregated and validated before they are submitted back to the service This pattern lends itself very well to applications such as an expense report tracker or a contact manager.
2. Submitting HTML form data to a service In Progress
One of the most common tasks that developers on the web face is submitting data from a HTML form into a database backend. Upon form submission, we need to ensure that the data is valid before we pass it to our data tier, so we need to build some validation logic into our service. To improve the client experience we also want to pre-validate the data on the client before we submit it to the server, using the same validation rules as the service itself. This provides a nice user experience, where the user can find out if the data is invalid without making a roundtrip to the server.
3. Generating a JavaScript SDK for a service Not Started
Today's HTTP-based public services are great because of the variety of client devices that are able to access them simply by virtue of understanding HTTP. However in some cases you want to make it very easy for JavaScript developers in particular to access your service, because you expect a large number of your APIs users to be web pages. The underlying service stays the same, but you generate a small redistributable .js file that understands the exact formats and URI structure that your service uses, and exposes that conveniently for developers. Consider APIs such as Bing Maps and Google Maps as examples of this scenario.
4. Building a JavaScript AJAX widget with a service Started
Similar to the preceding scenario, sometimes you want to create a tailored client-side experience for your API, to make it very easy to access the API from webpages. The difference between this scenario and the preceding JavaScript SDK scenario, is that in this case your customers don't even have to learn JavaScript. In this scenario you provide a self-contained widget that knows how to interact with your service: all the customer needs to know is how to copy/paste your widget reference into their page. Consider the widgets provided by WeatherBug as examples of this scenario.

More scenarios coming... leave us your feedback in the comments about what scenarios you would like to see

Blog posts

Jeff Handley
Tomasz Janczuk
Yavor Georgiev
Carlos Figueira
 Yavor Georgiev's Blog News Feed 
Sunday, October 07, 2012  |  From Yavor Georgiev's Blog
 Yavor Georgiev's Blog News Feed 

 Carlos' blog : codeplex News Feed 
 Carlos' blog : codeplex News Feed 

External resources

File bugs

To file a bug against features from this project, please use the Issue Tracker tab. Be sure to select "jQuery" as the component when filing a bug.

Last edited Feb 17, 2012 at 9:17 PM by danroth27, version 36


rlasker3 Sep 7, 2012 at 4:25 PM 
From an enterprise perspective we need to be able to tie in our Claims Based SSO into the WCF service so that users can authenticate to the service by passing their claims token.

johnhbarrett Mar 18, 2011 at 1:10 AM 
fantastic stuff guys - i'll be following this with much anticipation.

pbromberg Dec 5, 2010 at 3:40 PM 
Please show an example of a GET REST - style request with parameters on the querystring.