WCF Data Services (OData) Vs ASP.NET Web API
There are currently other major differences between WebApi and WCF Data Services, which no one ever seems to mention. I wish MS would come out with a good article comparing the two.
I've been following OData for a while and also WebApi. I've always found a few major distinctions.
First, I'm not sure what your boss means by "MS is backing WebApi", as to mean they aren't backing OData?? IMO, they are backing both and currently there is some minimal overlap. Windows Azure Data Market exposes their Data using OData, Azure Table Storage uses OData, SharePoint 2010 allows OData Queries over it's Data, and other Products from MS are also supporting it, such as Excel PowerPivot. It's a very powerful Query framework when it comes to relational Data. And because it's RESTful, any language, framework, device, etc can integrate with it.
Here is what I like about OData + WCF Data Services:
OData + WCF Data Services has finally allowed Client Applications to be more "expressive" when querying Data over the Web. Before, we always had to use ASMX or WCF to build rigid Web APIs which get unwieldly and require constant changes whenever a UI wants something slightly different. The Client Application could only specify parameters to dictate what criteria to return. Or do like I did and "Serialize" LINQ Expressions and pass those as the Parameters and re-hydrate into Expressions<Func<T,bool>> on the Server. Its decent. Got the job done, but I want to use LINQ on the Client and have it translated over the Web using REST, which is exactly what OData allows and I don't want to use my own "hack" of a solution.
It's like exposing "TRANSACT SQL" without the need of a DB Connection String. Simply provide a Url and whoala! Start querying. Of course, both WebApi and WCF Data Services support Authentication/Authorization, so you can control access, append additional "Where" statements based on roles or other data configuration. I'd rather do this in my Web Api Layer than in SQL (like building Views or Stored Procs). And now that Applications can build queries themselves, you'll see Ad-Hoc and BI Reporting tools starting to leverage OData and allow Users to define their own results. Not relying on Static Reports where they have minimal control.
When developing in Silverlight, Windows 8 Metro, or ASP.NET (MVC, WebForms, etc), you can simply add a "Service Reference" in Visual Studio to the WCF Data Service and quickly start using LINQ to query Data AND you get a "Data Context" on the Client, which means it tracks changes and allows you to "Submit" your changes atomically back to the Server. This very similiar to RIA Services for Silverlight. I would have used WCF Data Services instead of RIA Services, but at the time, it did not support DataAnnotations or Actions, but now it does :) WCF Data Services has another advantage over RIA Services, which is the ability to perform "Projections" from the Client. This can help with performance, incase I don't want to return all Properties from an Entity. Having a "Data Context" on the Client is great when dealing with Line-Of-Business Apps.
So, WCF Data Services is great if you have Data with relationships, especially if you are using SQL Server and Entity Framework. You'll quickly be able to expose Queryable Data + Actions (calls to invoke operations, i.e. workflows, background processes) over REST with very little Code. WCF Data Services was just updated. New release launched. Check out all the new functionality.
The downside to WCF Data Services is the "control" you loose over the HTTP Stack. I found the biggest flaw was in the IQueryable<T> Methods which return Collections. Unlike RIA Services AND WebApi, you DON'T have full access to develop the logic in the IQueryable Method. In RIA Services and WebApi, you can write whatever code you want as long as you return IQueryable<T>. In WCF Data Services, you ONLY get access to append a "Where" Statement using Expression<Func<T,bool>> interceptor Methods. I found this disappointing. Our current application uses RIA Services and I find we really need the ability to control the IQueryable logic. I hope I'm wrong on this and I'm just missing something
Also, WCF Data Services does NOT yet fully support all LINQ Operators either. It still supports more than WebApi though.
What about WebApi???
- I like the control over Http Request/Response
- It's easy to follow (leveraging MVC patterns). I'm sure more tooling will come.
As of now (to my understanding), there is no "Data Context" support on Client (i.e. Silverlight, ASP.NET Server-Side Code, etc), because WebApi isn't really about Entity Data Models like WCF Data Services/OData is. It can expose Collections of Model Objects using IQueryable/IEnumerable, but there are no Primary Key/Foreign Key "Navigation Properties" (i.e. customer.Invoices) to use once the Entities are loaded on the Client, because there is no "Data Context" which loads them asynchronously (or in one call using $expand), and manages the changes. You have no code-generated "representation" of your Entity Data Model on the Client, like you do in RIA Services or WCF Data Services. I'm not saying you can't/don't have Models in the Client that represent your Data, but you have manually populate the Data and manage which "invoices" are to be set with each "customer" once they are retrieved over the Web. This can get tricky, specially with all the Async stuff going on. You don't know which calls will come back first. This may be hard to explain here, but just read about the "Data Context" stuff in RIA Services or WCF Data Services. So when dealing with Line of Business Apps, this is major issue for me. This is mainly based on productivity and maintainability. You can obsolulately build Apps without a Data Context. It just makes things easier, specially in Silverlight, WPF, and now Windows 8 Metro. Having relational Entities loaded into memory asynchronously and having Two-Binding is really nice to have.
Having said that, does this mean some day WebApi can support a "Data Context" on the Client? I think it could. Also, with more tooling, a Visual Studio Project could generate all your CRUD Methods based on a Database Schema (or Entity Framework).
Also, I know I'm only mentioning .NET to .NET Frameworks when it comes to working with WCF Data Services or WebApi, but I'm very aware that HTML/JS is also a major player. I was just mentioning the benefits I've found when dealing with a Silverlight UI, or ASP.NET Server-Side Code, etc. I believe with the advent of "IndexedDB" in HTML5/JavaScript that having a "Data Context" and a LINQ framework in JavaScript could also become available, making the ability of querying OData Services even easier from JavaScript (you can use DataJS today with OData). Plus, using KnockoutJS to support MVVM and Binding in HTML/JS as well, will make it a breeze :)
I'm currently researching which platform to use. I'd be happy using either, but I tend to lean towards OData based on the fact that my next Application is primarly about Analytics (read-only) and I want a rich expressive RESTful Api. I believe OData + WCF Data Services gives me that because WebApi only supports $take, $skip, $filter, $orderby over Collections. It does NOT support Projections, Includes ($expand), etc. I don't have a lot of "Updates/Deletes/Inserts" and our Data is fairly relational.
I hope others will join in the discussion and give their thoughts. I'm still deciding and would love to hear other opinions. I really think both are frameworks are great. I wonder if you have to even choose, why not use both if needed. From the Client it's all about building REST calls anyways. Just a thought :)
This is a subjective question, so here's a subjective answer. IMO, WCF has way too much overhead for simple RESTful services. Web API, on the other hand, was designed specifically for RESTful services.
I'm in agreement with Dave Ward on this. Check out his blog for more information.
I’ve long held out against pressure to move from ASMX to WCF in WebForms projects, because accepting WCF’s complexity primarily only rewarded me with less flexible JSON serialization. By contrast, I’ve begun converting some of my projects from ASMX to Web API, and have been pleased with how easily Web API replaces ASMX.
I believe Microsoft has finally found a good balance between ASMX’s simplicity and WCF’s power with Web API.
We believe that Web API provides the right platform for OData services going forward and as such will be investing primarily in that platform for OData server stacks. We will of course continue to put significant resources into the OData core libraries and client, but we do plan to reduce investment in WCF Data Services as a stack for creating OData services.
OData Team Blog
So, seems now everything is clear enough
Both Web API and WCF Data Services support OData out of the box. With WCF Data Services (WCFDS), it's automatic. With Web API, return IQueryable from your controller and tag the method with [Queryable]. This will get you the $filter functionality you were talking about. And if you go about it this way, both can handle JSON in the response automatically by putting accept=application/json in the request header. The OData from WCFDS supports a few more OData keywords than the Web API (although only the $expand keyword comes to mind), but I'm sure time will remedy this.
Both .NET clients and HTML pages can call into both of these alternatives easily, but if you like LINQ, and you are building .NET clients, WCFDS can be added into your project as a service reference. This allows you to skip all of the HTTP business altogether and directly query the collections.
The bottom line is that there is nothing preventing you from putting .svc files into your ASP.Net MVC project. It isn't an either-or proposition. Adding data services to your server will save you the need to write lots of controllers, but doesn't prevent you from writing additional controllers if you wish.