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!!
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 :
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.
Here are a couple of books that I recommend about WCF Programming and WebAPI.