Comparing Web API 2 and WCF for building services on HTTP and REST
From my archive - originally published on 6 February 2014
On the face of it, Microsoft took WCF’s promise of “one implementation, any protocol” and shot it in the head with ASP.NET Web API. After all, the Web API seemed to emerge from an increasingly fragmented landscape where Microsoft had failed to nail HTTP service provision with WCF.
The original goal of WCF was to support SOAP and WS-*services across a number of different transports. The same contract could be applied to a different transport just by changing the binding configuration. Support for HTTP services was added in .Net 3.5 via WebHttpBinding in recognition of the need to provide non-SOAP services over HTTP.
Despite attempts to enhance HTTP service provision through successive releases of WCF, the two have always seemed slightly uncomfortable bedfellows. At the heart of this is the fact that HTTP and REST do not fit very well into the core WCF abstraction that separates the service contract from the underlying transport.
HTTP is not just another transport protocol
The problem is that HTTP is not just another type of transport. It’s an application-level protocol that provides a set of features that can be directly leveraged by RESTful APIs:
- It supports a series of verbs that define actions – e.g. GET for fetching information and DELETE for removing it.
- It contains message headers that can be used to describe messages as well as caching and securing it.
- The message body can be used for a wide range of data, not just a structured XML response.
- The system of URLs can be used to define resources and actions to provide an intuitive and navigable resource API
These features are central to the design and functionality of RESTful APIs and cannot be meaningfully separated from the underlying protocol. WCF’s core abstraction that separates the service contract from the underlying transport binding is not valid for RESTful APIs.
The cruft comes for free with WCF
Although WCF can still be used as an implementation technology for an HTTP service, a common complaint is that it tends to add a lot of Microsoft-specific cruft to messages by default. This can be an issue when taking a contract-first approach to service design where the clarity and cleanliness of the request and response messages are emphasised.
This is particularly relevant for RESTful services and WCF doesn’t give you the same level of control over messages that you get with Web API. A fair amount of detail gets added to a service response out of the box, including namespaces on the header element and a few bonus headers.
These additions are particularly unwelcome for carefully designed RESTful services that demand more direct control over payloads, headers, response codes and HTTP verbs. Having an implementation stack that inserts its own decoration to the contract will only undermine the clarity of a good REST API.
With power comes responsibility
The extra control that Web API gives you does have a downside from a governance perspective as it does not offer any facilities for controlling interface definitions. It is easy for developers to make small and unnoticed changes to service interfaces by adding an extra header or returning an unexpected status code.
WCF’s service and data contracts do provide a more explicit interface definition. This gives rise to a clearer definition that can be managed and versioned much more easily. The Web API does not let you define explicit contracts in quite the same way, so more discipline is required to avoid unplanned breaking changes.
Complimentary technologies. Really.
Since the WCF and ASP.NET teams have merged much of the fragmentation that lingered around Microsoft’s HTTP service stack has been resolved. They appear to have settled on a strategy where they direct you towards WCF to create web services that accessible over a variety of transports and ASP.NET Web API to create REST-style services
The emergence of ASP.NET Web API provided a more specific programming model for HTTP. Where WCF allows you to build services that support multiple transports and encodings for the same service, the Web API allows you to far greater control over HTTP services and different media types. Improvements in the most recent release such as attribute routing and IHttpActionResult have deepened this level of control.
SOAP and REST are completely different styles of service and cannot be compared directly. REST may be gaining ground due to its simplicity, but there are a lot of good reasons to use SOAP, particularly if you want to leverage the WS-* standards for enterprise security, ACID-compliant transactions or reliable messaging.
WCF offers more flexibility over channels where you can use faster transports such as TCP, named pipes or even UDP. If speed is of the essence and your hardware infrastructure allows it then you may be better off using WCF. It also allows you to develop more specialised services such as one-way or duplex messaging.
If you want to build fully RESTful services that leverage all the features of HTTP then the Web API is a better choice. Features such as cache control for browsers, concurrency control via ETags and using different content types are easily implemented with the Web API. It’s possible to do much of this stuff with WCF, but there’s little benefit in doing so.