It’s funny, when alternative technologies comes out that do a similar thing to a previous technology, people are very quick to pronounce the previous technology as dead. I was talking to someone the other week at a different company who said that their architects wanted to use WebAPI because WCF wasn’t relevant any more. This made me think, WHAT!!, REALLY!!, SURELY NOT!!

WCF is Dead. All Hail Web API
WCF is Dead. All Hail Web API

In the rest of this article I want to briefly cover what WCF and WebAPI are, talk a bit about the differences, and then suggest the reasons why you may use either. This isn’t an exhaustive discussion, but the point is that you can have various technologies doing similar things, without either one of them being redundant. I have spent the last 7 years of my career being involved in service architectures built using WCF and I am certainly not thinking I need to replace any of those systems just yet.

Windows Communication Foundation

Windows Communication Foundation (WCF) is a framework for building service-oriented applications. Using WCF, you can send data as asynchronous messages from one service endpoint to another. A service endpoint can be part of a continuously available service hosted by IIS, or it can be a service hosted in an application. An endpoint can be a client of a service that requests data from a service endpoint. The messages can be as simple as a single character or word sent as XML, or as complex as a stream of binary data. A few sample scenarios include:

    • A secure service to process business transactions.
    • A service that supplies current data to others, such as a traffic report or other monitoring service.
    • A chat service that allows two people to communicate or exchange data in real time.
    • A dashboard application that polls one or more services for data and presents it in a logical presentation.
    • Exposing a workflow implemented using Windows Workflow Foundation as a WCF service.
    • A Silverlight application to poll a service for the latest data feeds.

While creating such applications was possible prior to the existence of WCF, WCF makes the development of endpoints easier than ever. In summary, WCF is designed to offer a manageable approach to creating Web services and Web service clients.

There is a good tutorial on creating basic WCF Services over at MSDN.

What is ASP.NET Web API

ASP.NET Web API is a framework that makes it easy to build HTTP services that reach a broad range of clients, including browsers and mobile devices. ASP.NET Web API is an ideal platform for building RESTful applications on the .NET Framework. Web API was originally a Microsoft side project that was developed on CodePlex, but it has now been formally integrated into ASP.NET. Here is an excellent tutorial that shows you how to get started with Web API.

Differences between WCF and WebAPI

When WCF was released back in the .NET 3 days, the main goal was to support SOAP + the WS service standards over a variety of different transports. Over time it became clear that although SOAP is wide spread and supported on many platforms, it is not the only way to go when creating services. There is also a need to also support non-SOAP services, especially over HTTP, where you can harness the power of the HTTP protocol to create HTTP services, services that are activated by simple GET requests, or by passing plain XML over POST, and respond with non-SOAP content such as plain XML, a JSON string, or any other content that can be used by the consumer. Support for non-SOAP services was very much needed in WCF back then, mostly because some clients, such as web browsers, were not that suitable to handle SOAP messages (plenty of XML parsing and DOM manipulation).

A new binding, WebHttpBinding, was added to WCF 3.5 that would help create non SOAP services over HTTP. This allowed you to create RESTful services, and this then morphed into the WCF REST Starter Kit which never got officially released past “Preview 2”, but some of the features did make it into WCF 4

The main goal of the Web APIs is to stop looking at HTTP through the eyes of WCF. That is just a transport protocol to pass requests. Rather, it allows us to look at it as the real application level protocol it is, a rich, inter-operable, resource-oriented protocol. The purpose of the Web APIs was to properly use URIs, HTTP headers, and body to create HTTP services for the web, and for everyone else that wished to embrace HTTP as its protocol.

SOAP and HTTP services are very different. SOAP allows us to place all the knowledge required by our service in the message itself, disregarding its transport protocol, whether it is TCP, HTTP, UDP, MSMQ or Named Pipes. But unlike these protocols, HTTP is an application level protocol, and as such it offers a wide variety of features:

    • Supports of verbs that define the action – GET, POST, PUT and DELETE.
    • It contains message headers that are very meaningful and descriptive – headers that suggest the content type of the message’s body, headers that explain how to cache information, how to secure it etc.
    • It contains a body that can be used for any type of content like JSON, XML, and Binary data.
    • It uses URIs for identifying both information paths (resources) and actions.

HTTP is a lot more than a transport protocol. It is an application level protocol, and the fact is that although many platforms know how to use SOAP, many more platforms know how to use HTTP. Among the HTTP supporting platforms which do not support SOAP that well are the browsers, probably the most important platform for web developers and users.

This does not mean that SOAP is redundant though. SOAP is still useful for building messages when you don’t have an alternative application-level protocol at your disposal, or when you want to use SOAP across the board while considering HTTP as no more than another way to pass messages (for example, use HTTP because it can cross firewalls more easily than TCP).

When should I choose WebAPI over WCF?

If your intention is to create services that support special scenarios like one way messaging, message queues, duplex communication etc, then you’re better of picking WCF.

If you want to create services that can use fast transport channels when available, such as TCP, Named Pipes, UDP, MSMQ and you also want to support HTTP when all other transports are unavailable, then you’re better off with WCF and using both SOAP-based bindings and the WebHttp binding.

If you want to create resource-oriented services over HTTP that can use the full features of HTTP – define cache control for browsers, pass various content types such as images, documents, HTML pages etc then Web APIs are the best choice for you.


WCF and Web API are not your only choices. Probably the most popular non Microsoft provided technology is ServiceStack. To describe what Service Stack is I shall use their own words.  Service Stack is :

Service Stack : An alternative to WCF and Web API
Service Stack : An alternative to WCF and Web API

A fast, unified and integrated replacement for WCF, WebAPI and MVC

    • Holistically constructed to reduce artificial complexity. Services are designed for maximum re-use.
    • Develop with idiomatic code-first C#, features naturally bind to and empowers your existing models.
    • POCO models can be used in all libraries as-is – offering un-precedent levels of re-use unseen in .NET.
    • Easy-to-use. Never read another text-book to learn how to use another heavy .NET framework again!

The Service Stack framework is very large and there are lots of great components to it. In terms of the REST, SOAP and Message Queuing aspects then Service Stack is a config-free, code-first web and services framework embraced around Martin Fowler’s remote-service best-practices in C#. There is implicit support for returning popular .NET’s response types, idiomatic handling of C# Exceptions and full-control over HTTP Responses.

Its message-based design provides the most advantages for remote services encapsulating them in their most re-usable form allowing the same service to be called in REST, SOAP, MQ services enabling .NET’s most succinct, end-to-end typed API without the use of code-gen, additional machinery or post build steps. The Service Stack framework provides a good alternative to WCF, WCF/REST, ASMX, WebAPI, MVC etc

Personally, if I was starting up a green field project, I would most like use Service Stack as my platform of choice. Here is a good tutorial on how to create a basic service with Service Stack.


So, WCF is not dead at all. Web API just means you have more choice. It is another tool in your tool box, along with frameworks like Service Stack. It is up to you to decide what the best tool is for your scenario, and I hope this short post helps you with that decision. This wasn’t meant to be an exhaustive look at the frameworks, but I wanted to stress the point that just because a new framework comes out that does something similar to WCF, doesn’t automatically make WCF redundant, and this goes for many things in software development. The bleeding edge doesn’t automatically replace everything else that was out before it.

Further Reading

Here are a couple of books that I recommend about WCF Programming and WebAPI. Paperback | Kindle Paperback | Kindle

Programming WCF services Paperback | Kindle Paperback | Kindle

pro web api

Participate with Coding in the Trenches on Facebook
Participate with Coding in the Trenches on Facebook by Click the button above.


    1. Interesting outlook on things 🙂 Microsoft make some very good technologies and I have made a very good career out of developing with them and leading developers who work with them. As with everything, there are good points and bad points to different technologies. What do you propose in their place out of interest?

      1. Wow! Anonymous has a positive, “as advertised” review. Convenient. The, “What we return in both cases is an array of “TestInfoStruct””. WHY are you dealing with arrays??? Serialization of complex objects is a huge advantage of wcf services. Help me out here; your test is based on an array, who uses arrays these days? Please explain.

  1. Web API is to WCF as a pinecone is to a pine tree. Web API provides a single transport mechanism, for a very specific purpose (or group of purposes). To say that Web API will replace custom TCP communications for LAN traffic is crazy, and to think that there aren’t times and places where custom TCP connections are appropriate is equally crazy.

    As you said, WCF is not dead. It was inevitable that new approaches and technologies were created since WCF, and will be created after Web API… and it is inevitable that WCF will die SOME TIME… but that time is not now. Not by a long shot.

    1. True. But I think you are missing the point. Web API really does a small subset of WCF. However, that subset is the only relevant communication means people are interested in. So, WCF is still important, but that importance is so low.

      1. Z,

        Thank you for your response. I find it difficult to keep up with everything and all the changes these days. I spent a lot of time learning WCF at the initial release and continue to use it to this day. I read from forums that it is, “heavy”. As a, .NET developer I have, over the years, wait to jump on-board with the latest when it comes to, Microsoft. Over the past few years since the release of, “MVC” and the use of using, Web Api and restful services using http as the transport mechanism, I have extended my services with additional endpoints and methods to handle both circumstances. I question myself if this is the correct way to address the issue…..

        Again thank you for your response

  2. WCF is dead. if u want duplex binding you are much better off using webapi odata and breeze.js so you can do linq like queries in javascript clientside with observables. WCF is awful and the only thing worst was silverlight which is also dead. good riddance. Get with the program man

  3. This article has been useful to me. I started with web services and realized that all its books are old. I then started learning WCF just to see that its books are also old. So thought of looking for a modern alternative to WCF. With your article, I will continue with the WCF. Thanks

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: