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

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.

 

ASP.NET Web API

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.

Tags:

ASP.Net | WebAPI | Windows Communication Foundation | OData

WebAPI or WCF?

by Matt Milner 28. February 2012 13:44

Updated [2/29/2012]: added more information on why HTTP and thus WebAPI is important.

I’ve been part of several conversations over the past few weeks where someone posited the question: Now that WebAPI is out, how do I (or my customers) decide when to use it or WCF? This question actually has many different flavors?

  • Is WCF done? Does WebAPI replace WCF? Should I stop using WCF HTTP?
  • Why is WebAPI part of ASP.NET? Wasn’t WebAPI originally a WCF framework?
  • If WebAPI is part of ASP.NET, why don’t I just use MVC? What does WebAPI give me over MVC?

 

Is WCF done?

WCF is not done, nor is it going away anytime soon. WCF is the framework to use to build services that are flexible with regard to transport, encoding, and various protocols. This was precisely what WCF was designed for and what it does extremely well. WCF enables me to write service code and contracts which can then be exposed over various bindings (transport, security, etc.). That hasn’t changed and continues to be the case. If you are building a service in your organization and plan to support multiple protocols, or simply use protocols other than HTTP (tcp, name pipes, udp, etc.) then WCF continues to be your choice.

If you happen to want to expose your service over HTTP with WCF you have two high level choices: SOAP over HTTP or web HTTP. Obviously SOAP over HTTP is simply a different endpoint/binding choice, again where WCF shines. You can also expose your service using the WCF HTTP model that has been around since .NET 3.5. This model changes the dispatching to happen based on URI templates and HTTP verbs rather than SOAP actions. The WCF HTTP model also provides some help in providing help documentation, surfacing faults in an HTTP friendly way (think status codes) and returning content in web friendly formats such as JSON. 

But, and there had to be a but, WCF was built as a transport-neutral fashion, that’s a selling point; except when you do care about the transport and really want to leverage HTTP for example.

 

Why is WebAPI part of ASP.NET and not WCF?

Somewhere during development WCF WebAPI became ASP.NET WebAPI.[1] Knowledge that this occurred is often what leads to the previous questions about the fate or uses of WCF. In my opinion, and this is just that, WCF as the backbone of WebAPI was not the best option because in order to care about HTTP you had to work around a lot of WCF infrastructure. Things the core Message abstraction were not built to embrace any transport and didn’t easily support (note I said “easily”) the various content types that might be negotiated.

When talking with colleagues and looking at what people are doing to build web APIs the most common choice was overwhelmingly NOT WCF. In fact, the top choices were either an open source platform or using MVC controllers to return JSON results to client pages. The reason, as I see it, is that all these platforms made it easier to get a web API up and running while allowing you close control over HTTP when you care. For someone simply trying to return some objects to a client as JSON within their MVC web application it is really simple to add a method to the existing controller and return that data. No configuration, no bindings, nothing but their models and existing controllers.

HTTP is important

Getting close to HTTP allows you to take advantage of the protocol. This means I can fully leverage features of HTTP such as caching, etags, status codes and the like. Why is this important? There are a variety of reasons but I’ll focus on a few. Caching GET requests is a huge part of HTTP and of scaling any web site/service. One of SOAPs big failings is that it relies exclusively on HTTP POST when using HTTP as a transport and so cannot take advantage of caching of requests, even if those requests are returning slowly changing or unchanging data. Getting close to HTTP allows me to set expiration headers easily on the response and control the caching of my content on the client intermediaries, etc.

Being able to work easily with ETags enables me to leverage conditional gets and manage application concerns such as concurrency. Status codes allow me to be explicit when responding to clients about what happened with their request.  As an example, when someone posts a new resource to my service I want to respond with success (2xx status code) but I also want to provide the right code indicating that the resource was created (201) and provide the location header so the client knows the exact URL of the resource just created. Being close to HTTP gives me the ability to send the appropriate status code and the appropriate headers so the client can get a richer response, all with the existing HTTP protocol.

 

It makes sense, when you care about HTTP, to use MVC . . . but MVC is not the best tool for building services either.

 

What does WebAPI give me over MVC?

ASP.NET MVC provides some great tools that could be leveraged for services including model binding and routing. For most people building web APIs, however, there are other concerns as well. As a simple example, I’ve always felt a little uncomfortable building services in MVC because of the standard routing model that includes the action in the URI. A little thing, sure, and something I could work around with some MVC extensions of my own. Web API provides me a model for routing based on HTTP verb rather than a URI that contains an action. This puts me close to the HTTP protocol, simplifies my routing and seems right to me. In addition, Web API allows me to fully leverage content negotiation to enable returning various representations of my objects/resources. This means I have a pluggable model for allowing the client to tell me what representation they would like (text/xml, application/json, text/calendar) and choosing the best formatter to create the best match representation. All this comes with the ability to use the routing, dependency resolution, unit testing, and model binding.

In addition WebAPI allows you to self-host your services a la WCF (and in fact uses a little WCF under the covers to enable this) so you can, if you choose, go outside ASP.NET / IIS as the host of your service and continue to leverage all these great benefits. This enables you to host your HTTP services in any  .NET appdomain and still use the same routes, controllers, etc.

 

So . . . ?

WCF remains the framework for building services where you care about transport flexibility. WebAPI is the framework for building services where you care about HTTP.

 

What do YOU think?

 

[1] To be exact, after the 6th preview release of WCF WebApi

Tags:

ASP.Net | Windows Communication Foundation | WebAPI

Pluralsight Developer Training

View my developer training videos on Pluralsight.

Pluralsight .NET Training