WCF Data Services and Web API with OData; choices, choices.

by Matt Milner 2. April 2013 15:13

Back in 2010, I wrote a course for Pluralsight on OData which covers the protocol in general and introduces the viewer to the client and server programming model. This year, Microsoft released updates to the ASP.NET Web API which includes support for OData in the controllers.  Since this latest release, I’ve received several questions about the differences between these two toolsets for building services that support OData and some guidance on which to use.  This is my attempt to answer those queries. 



OData is a protocol developed by Microsoft and others for data access using web protocols such as HTTP, ATOMPub and JSON. One of the benefits of OData is a consistent query experience, defined in the protocol, that enables rich querying using URI query string parameters. This consistent query syntax, much like ANSI SQL, provides a platform neutral API for working with data.

This means I might be able to write a query like this:

http://pluralsight.com/odata/Categories?$filter=Name eq 'OData' 


There are a variety of query string options you can use to filter and identify the resource(s) you want to read or update. I can use this same pattern to apply filters to other OData services using their entity properties.


WCF Data Services

WCF Data Services is Microsoft’s library for building OData Services  or writing OData clients.  On the server side, the framework provides a very quick, simple model for exposing all or part of an Entity Framework model as an OData compatible service with little or no code. This service, scaffolded in minutes supports, if configured to allow it, read, insert, update and delete. 

If you don’t have an Entity Framework model, you can expose a simple .NET object with IQueryable properties for read only access, or implement the IUpdateable interface and support update, insert and delete on any collection. 

This framework provides the quickest way to get a service up and running when the data model is the primary focus of your application. You do have the ability to extend the service with functions that are exposed over the HTTP API as well. For example, at Pluralsight we could have a method to return the top 10 courses. This might be a convenience to save the client from having to compute this themselves, or it might be because the data needed to make that distinction isn’t exposed in the data available in the service therefore the client couldn’t compute or filter to get those same results. 

On the client side, the WCF Data Services library provides a .NET interface over the OData protocol and exposes the query semantics as a LINQ provider.  This enables .NET developers to access the data in an OData service as they would any other data source.

Microsoft has been moving some OData features into the OData Library to enable reuse in many different scenarios.  This means you don’t have to accept the default WCF Data Services model, especially if you don’t have an EDM for your data source. 

You can, obviously, use the client and service independently.  That is, even if you develop your service using another framework, perhaps not even Microsoft, you can use the client library to access it.



The ASP.NET web API was introduced last year as a framework for building HTTP services; that is services that expose their functionality over HTTP (these may or may not be REST services). You build these services using controllers, much like ASP.NET MVC development for web applications.  The services are most often focused on exposing certain resources and enabling various actions on those resources.

One of the features of ASP.NET Web API is content negotiation. This enables a client to request a resource, a Course for example, and indicate (using the HTTP accept header) they would like the response in JSON, XML, or any other format. If the server can support the response type, it does so, serializing the data appropriately. 

It is only natural that customers would want OData JSON or ATOMPub as a format for exposing their resources, and would request support for the query syntax. The beauty of OData is that you don’t have to write umpteen methods for querying (GetCustomer, GetCustomersByCity, GetCustomersByRegion, etc.). So, using pieces of OData Lib, the Web API team enabled support of OData query syntax on an API controller method and enabling update semantics as well. 


Making the decision

Having said all that, I would summarize as follows: WCF Data Services focuses on the data model and limits code, while Web API focuses on the controller/code and enables the formatting and query syntax of OData.

So, 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, however, you are building an API and simply want to expose some resources using either OData query syntax or formatting, then ASP.NET Web API is probably the best place to start. 

I hope this is helpful and have fun writing your services no matter what toolset you choose.


ASP.Net | WebAPI | Windows Communication Foundation | OData

Comments (6) -

Onur United States
8/24/2013 5:45:34 PM #

This article is actually very shallow. I am sorry to say but the point of WCF Data Services is not the ease of use at all. On the other hand it could be far more complicated and difficult than web api once you start customizing things.

While both uses url to generated a linq expression over IQueryable's, The point is, WCF Data Services focuses on Proper "but not quicker" Entity Domain model, supporting things like lazy loading, paging etc
Web API on the other hand simply serializes given objects.

Milton United States
9/19/2013 2:20:21 PM #

Are they restricted to online applications ?
Is there support for client side caching ?  If so, can you create a blog on that ?

Thanks !

mmilner United States
1/27/2014 11:05:29 AM #

Onur, WCF Data Services, in the most basic form, pushes you to expose your entity model as the service model. You could argue that it forces you to focus on a proper model, but I'd argue that you either will or won't do a good job of that in either case. When you use WebAPI, I think you get more control over the model that is exposed because you are writing the code to handle the requests. That means I don't have to expose my entity model to the world, I can use a DTO or some other intermediate form for the client.

Don't get me wrong, I like WCF data services for what they provide, but once you get into the advanced scenarios and start writing a lot of code I think you need to consider if it is a good match or if you'd get more benefit out of writing that code in a Web API instead.

Ed Ferron
Ed Ferron United States
5/24/2014 6:49:20 AM #

Nice summary, quick and to the point, which is exactly what I needed. I have a super simple scenario, and of course my client is 2+ generations behind on runtimes (older tech). So I am going to go with WCF Data Services, especially given it is an internal app. I was working on making the decision between WebAPI and WCF Data Services and this helps.


Gary United States
3/13/2015 10:15:57 AM #

What about OData for non-open data, ie, restricting data by user permissions? It seems that when using OData the server coding work is reversed -- everything is possible to query, and we must work to close of what certain users shouldn't be able to access/modify/delete. Yes? Or?

Mat Milner
Mat Milner United States
3/13/2015 10:39:37 AM #

Gary, for security you can use traditional security measures to protect the service such as Basic, NTLM, etc.
For the entities exposed in a WCF data service you can also decide which entities from your model are exposed as part of the service.
To your point about user permissions, I don't think that's any different in oData/WCF data services. You'll need to apply permissions to the entities determining what operations users are permitted to invoke. You can do some of this in code and some in declarative permissions .
For WCF data services you can use ASP.Net security config to declare the users/groups and restrict certain HTTP methods to those users. Or you can write interceptors that add filters the outbound data and perform checks on inbound data.
In Web API you can similarly restrict users with authorization filters on the controllers or operations and add your additional filters in the controllers as well.

By default your WCF data service doesn't expose any entities so you have to Opt in for those items. If you are trying to only return certain fields, then using Web API gives you the ability to customize the objects you send back so you can expose only what you choose.

Pingbacks and trackbacks (2)+