WCF Data Services (OData) Vs ASP.NET Web API

Question

I am designing a distributed application that will consist of RESTful services and a variety of clients (Silverlight, iOS, Windows Phone 7, etc). Right now I'm determining which technology I should use to implement my services, WCF Data Services (OData) or the new ASP.NET Web API that's coming out with ASP.NET MVC 4.

I've watched a few presentations online about each and right now I'm leaning towards WCF Data Services primarily because of the filtering mechanisms built into the URI and native hypermedia capability. The only downside I can see is the verbosity of the Atom Pub specification as opposed to POX.

Is there anything I should know about these two technologies before making a decision? Why would someone choose ASP.NET Web API over WCF Data Services?

Kahl

Answer 1

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.

Dakotadal

Thanks for the answer! I have a follow-up question so I hope you're pretty familiar with the ASP.NET Web API. One thing I liked about WCF Data Services is the hypermedia capabilities. Using their Netflix example, you could query a genre of movies and out of the box the service would return links to each movie in that genre instead of the entire entry for each movie. Is there a way to do that with the ASP.NET Web API? It looks like it gives you the entire expanded object structure instead of utilizing hypermedia. – Kahl

I haven't had a chance to use it yet, but it looks like you can implement MediaTypeFormatter to format your responses. See code.msdn.microsoft.com/Contact-Manager-Web-API-0e8e373d for a sample. – Dakotadal

That's kind of a pain. I was hoping there would be some kind of configuration to turn that on. And if would happen automagically. My boss is pushing for Web API because all of the powers that be at MS are backing it. It all seems will and good. It's payload is more concise than OData, it has the URI querying capabilities of OData, it's just missing out-of-the-box hypermedia. Maybe it'll find it's way in there by release time. – Kahl

I think this answer should be re-review as Microsoft is emphasizing to use OData Web API over Web Api. – Milamilady

Answer 2

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???

1. I like the control over Http Request/Response
2. 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 :)

Frigate

Web Api has a new preview for OData support that adds missing peacies and puts it on the same foundation that WCF DS uses: [link][blogs.msdn.com/b/alexj/archive/2012/08/15/… – Hannus

@JohannesRudolph - The link you gave sounds interesting but is broken. – Broody

OK, think it's just a formatting problem. It should be: blogs.msdn.com/b/alexj/archive/2012/08/15/…. – Broody

Web Api also just needs this small bit of love to work on versions of Excel prior to 2013: aspnetwebstack.codeplex.com/workitem/820 – Excellence

btw $expand is supported now days, isn't it? – Pergrim

That was an amazingly in depth response. I used Web Api for its simple REST capabilities and familiar routing, but didn't realize that it supported ODATA. Thanks for all the work you put in to this. – Gualtiero

As we are in 2014 now, Microsoft has an interesting blog post blogs.msdn.com/b/odatateam/archive/2014/03/27/… to discuss the future of OData support from WCF and WebApi. – Wellington

We are in 2016 now, and you can make OData controllers specifically for this purpose (Which replace the default WebAPI controller) – Mitsukomitt

This post is really championing OData, but for new readers today the Web API implementation of OData is a lot more mature and is now a great replacement for the WCF implementation. – Huffish

Answer 3

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

Hubble

Answer 4

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.

Optometer

Answer 5

In other words :

If you are looking to expose a data model (EDM or otherwise) quickly and don’t need a lot of code or business logic, WCF Data Services makes that REALLY easy and would be a good starting point.

If, you are building an API and simply want to expose some resources (and logic) using either OData query syntax or formatting, then ASP.NET Web API is probably the best place to start.

http://mattmilner.com/Milner/Blog/post/2013/04/02/WCF-Data-Services-and-Web-API-with-OData;-choices-choices.aspx

Unaccountedfor

Answer 6

Devaron gave the most informative review of WCF vs Web Api that I have yet to find. Thanks. Now to the point of WCF being too complex, I'll say that complexity is not automatically a negative. You'll be thankful for the breathing room it affords you in the future. The challenge as always with Microsoft tools is that we don't know or control that future. Let's hope that Microsoft ends up with a more unified system, and that it stays around for a few years.

I've also got a big system to build, and it stresses me out that the path isn't more clear. I plan on holding off for a couple more months while this all settles out. And personally I'm rooting for datajs (also check out JayData)

Erikaerikson

Answer 7

Just put it this way in simplest terms, step back from underlying protocol and look at this from developer/user perspective. Web API is Microsoft's first class HTTP based Rest Framework not WCF. That means any missing Rest features, specifications, they are going to add to Web API pipe and not necessarily to WCF.

Yes you can implement these yourself in WCF but as it says in the sentence you need to implement these yourself.

Just as an example today implementing a 2 factor authentication for a Web API takes less than 15 minutes using OWIN which is a primarily Authentication/Authorization nuget package that started as an open source project.

When you use a technology stack it makes a huge difference to use the first class stack for Microsoft. You would even have countless MS published sample code and projects in Github which you can simply copy and make a head start in your own project. It makes a difference on every level, documentation, code samples, feature set, support, helper api s you name it.

So my simple advice to you, if you want to build Restfull HTTP based applications use web API (or ASP.NET Core for portability) and really stay away from WCF. If the protocol is not HTTP and it really cannot be HTTP then use WCF.

Baerl

Answer 8

This is the TL;DR answer to this question.

WCF is the swiss army knife to WEB API's screwdriver for data communication and transfer: WCF can do everything WEB API can do, but, if you need more (e.g., using TCP protocol), WCF is the way to go.

Here is a great comparison.

WEB API

Number one reason to use WEB API is that it is lightweight. This means it is simpler to implement, easier to learn, easier to maintain, etc. It is specifically designed for the Web, which needs RESTful web services over HTTP. It does this and it does it well. If, this is all you need, WEB API is probably the way to go.

Also, it is Open Source (if you care)

WCF

WCF just does a lot more than WEB API: it supports multiple transfer protocols, multiple exchange patterns (WEB API requires integration with SignalR or Web Sockets), SOAP services can be described in WSDL, has additional security features, and more. Go with WCF if you require this additional functionality.

OData

OData is simply

An open protocol to allow the creation and consumption of queryable and interoperable RESTful APIs in a simple and standard way. source: http://www.odata.org/

In other words, high level, it is just standardizing a specific grammar for RESTful HTTP requests. Which will provide the same benefits as any protocol. And as of at least 2013 both WCF and WEB API allow the use of OData. So, it probably isn't worth worrying about OData.

Embryotomy