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


ASP.Net | Windows Communication Foundation | WebAPI

Comments (10) -

Leo Gorodinski
Leo Gorodinski United States
2/29/2012 5:04:58 AM #

The fact that HTTP is made explicit in ASP.NET WebApi is the selling point. HTTP is not just a transport protocol, but an application protocol, with application layer concerns. In WCF HTTP becomes hidden behind layers of abstractions and while it is certainly possible to create an HTTP service using REST, it adds needless complexity. In other words, the abstractions in WCF work, but utilizing those abstractions is difficult for the programmer. There is a delicate balance between abstractions and concretions that is closely tied to how the human mind operates. For building HTTP services, the WebAPI is an abstraction shift in the right direction.

Dennis van de Laar
Dennis van de Laar Netherlands
2/29/2012 7:29:13 AM #

Hi Matt,

I totally agree with you. Microsoft introduced WCF to make sure that there was one programming model for different kind of distributed solutions (MSMQ, Remoting, ASMX, etc). When they started with WCF Web API it felt like they where heading back to the old days. Giving developers more control over HTTP means leaving a generic programming model behind and make it more specific for HTTP. When they introduced WCF Web API i had my doubts because it was the contrary of one generic programming model. By introducing ASP.NET Web API you got best of both worlds. There is still a generic programming model which has a lot to offer when it comes to security, transactions, different protocols, etc and there is a possibility to get full control over HTTP with web API



mmilner United States
3/1/2012 9:47:43 AM #

Jack, HttpClient allows you to easily do GET, PUT, POST, DELETE, with typed parameters. I'm curious what you are looking for that is similar to webHTTP? In that model you can have a contract and it translates method calls to URIs and HTTP bodies but that model assumes an RPC  paradigm. In HTTPClient, you can still create a wrapper if you want, but a lot of what HTTPClient provides you is access to the HTTP constructs you are about, control over URI and payload.

Erik Porter
Erik Porter United States
3/7/2012 6:40:56 PM #

Your summary nailed it (says the new PM for MVC). Smile

Fernando Correia
Fernando Correia Brazil
3/28/2012 5:20:55 AM #

That's the kind of guidance and clarification we need. Thank you for that. Please also explain where WCF Data Service fits in this new vision. It implements RESTful services over HTTP. Will it be migrated into ASP.NET? Is Microsoft still backing its statement about OData "enabling a new level of data integration and interoperability across a broad range of clients, servers, services, and tools"? Is the RESTful style being deprecated in favor of the RPC style of DbDataController in the new ASP.NET Web API? In short, is WCF Data Services still the go-to place for exposing Entity Framework data over HTTP?

Sam United States
5/15/2012 7:15:02 AM #

As a long time WCF developer, I do not like this move. It seems Microsoft is trying to force WCF service programmers to now be web programmers. From what I see in the industry, I see people that write services and back-end components and then there are the people who do the web stuff, JavaScript etc and now we have to learn MVC which just seems totally ridiculous.

We will have web developers who are not otherwise skilled enough to understand services trying to write services and then when they don't work correctly, how will they know how to fix it? Reminds me of the VB6 days when Microsoft made things easy for developers which led to masses of poorly trained programmers writing what they considered to be enterprise applications.

Bad move Microsoft!

Karl Kininmonth
Karl Kininmonth Singapore
6/25/2012 3:24:04 PM #

Great, thank you. Clear and to the point. I've worked with both, and I agree completely.

Thomas Junk
Thomas Junk Germany
12/11/2012 7:07:33 AM #

Like CORBA is dying, WCF is dying too. HTTP and the web is the way to go. Think of the consuments of your services: most clients are consuming via web. So why this overhead WCF, when you want WEB API.

Steve Morrison
Steve Morrison United States
3/21/2013 9:21:41 AM #

On comparing Net.TCP WCF vs. Web API Here are my tentative impressions, with more questions than answers. I would appreciate your corrections and answers.

a) TCP/IP - Both can do this.
b) RESTful API - both can do this, though WCFmust use WebHttpBinding, not net.tcp binding.
c) Non RESTful API - Is WCF better, or the only way to go?
d) Over TCP/IP which is faster? And how about WWS, a Microsoft C++ method that is supposed to by 2 1/2 faster the Net.TCP WCF.
e) For http cached read requests, Web API has this and WCF does not.
f) Under IIS which is more robust with regards to failed connections, socket problems, etc.?
g) Configuration functionality - WCF wins here; it has extra flexibility.
h) Configuration simplicity - Web API wins here; WCF has extra complexity.
i) Ease of use for a newbie who knows neither - I assume Web API wins here.
Are there important points that would add business value, ease of maintenance, etc. that I am missing?

Chris W
Chris W Finland
10/31/2013 3:34:22 AM #

You should also consider Service Stack instead of WebAPI - a very nice framework and fast !

Pingbacks and trackbacks (8)+

Add comment

  Country flag

  • Comment
  • Preview

Pluralsight Developer Training

View my developer training videos on Pluralsight.

Pluralsight Hardcore Training