Architect's Master Class

ASP.NET Web API vs WCF – Where do we go from here?

By: Brian Noyes

With the recent release of the ASP.NET Web API Beta as part of the ASP.NET MVC 4 Beta, there are a lot of people confused about the positioning of the ASP.NET Web API vs WCF vs previous incarnations of the ASP.NET Web API. There is also a lot of confusion around when you should use which, and what the upcoming release of Web API means for the future of WCF. I’ll try to address both of those concerns here.

First lets start with a little history. In .NET 3.5, the WCF team added support for a WebHttpBinding and “WebHttp” endpoints, which they further enhanced slightly in WCF 4. These were an attempt to bolt on some support for building simple, non-SOAP-based HTTP services services (aka “Web APIs”) on top of the existing WCF message pipeline. REST was starting to get very popular in that timeframe and there was a lot of pressure being put on Microsoft to provide a solution for building RESTful solutions. WebHttp endpoints were their first attempt to provide support for doing so.

There was a fundamental problem with that approach. The WCF stack was really built from the ground up around SOAP messaging. When WCF uses HTTP, it is using it as nothing more than a transport protocol, similar to how it uses TCP, Named Pipes, MSMQ or any other wire level protocol. HTTP itself is capable of handling much deeper semantics, and that is what REST and Web APIs want to leverage. However, trying to tack a façade on the top of the WCF channel stack that exposes the full capabilities of HTTP is about the same as trying to tack a Hollywood façade of an old west prairie town on a modern skyscraper – there is a fundamental impedance mismatch there.

So really Microsoft needed a “do-over” for providing support for Web API and REST services by building a stack to support that from the ground up, like they did for SOAP with WCF. They needed to expose the ability to stand up really simple RPC style services with HTTP and needed to be able to support the full range of capabilities needed to support truly REST-based architectures.

The truth is that many people who claim to be doing or want to do REST have no idea what that really means. The true definition of REST is an architectural style defined by Roy Fielding’s thesis. That architectural style defines a number of constraints. If you are not satisfying all of those constraints, you are not truly doing REST as it was originally defined. Now many use the term RESTful as a mitigation to that – really meaning REST-ish, or partially satisfying the architectural constraints that define REST. To be more precise though, experts on REST are pushing for people to stop using the term REST unless you are fully complying with the architectural style. The alternative term that many are using for the middle ground, or things that follow some of the REST architectural constaints but not all is to call them a “Web API”. Thus the name of the new stack – it is a stack for building Web APIs or full blown REST services.

Using the ASP.NET Web API it is very simple to create and expose a service that just exposes some functionality and data over HTTP, and it is only incrementally more difficult to add more and more of the REST architectural constraints or features to your services. ASP.NET Web API started out as a spin off team from the WCF team, and there were earlier public previews of what they were working on that were called WCF Web API. If you have heard that terminology, erase it from your brain – there is no such thing as WCF Web API any more. What happened was that Microsoft recognized that it is confusing for customers to have too many framework capabilities that appear to do the same thing at first glance. And there is a natural alignment between these Web API services and the part of the framework that was built to be an HTTP pipeline from the start – ASP.NET.

Why do you need Web API when you have WCF? WCF works fantastic and is powerful, flexible, secure, and robust for remote communications between components when the client and service are both .NET. WCF is also an implementation of a collection of WS-* interoperable protocols. The only problem is that not many other platforms and frameworks ended up implementing those protocols, and even those that did have certain differences in their implementation that prevent them from being truly interoperable across a wide variety of platforms. So if you really want services that can be exposed and easily consumed from many platforms, particularly mobile devices such as phones and tablets as well as client side web page script, you need simpler services and you need to support different message formats other than SOAP. Additionally, WCF does suffer from a complexity barrier that some find too daunting to tackle when “they just want a simple service”.

ASP.NET Web API cannot do everything WCF can do – it does not support the full range of security models, reliability, transactions, multi-hop addressing, callbacks, and so on that WCF can do based on its supported protocols. But that is OK because not everyone needs those. Silverlight, WinRT/Metro, client-side JavaScript, iOS, and Android clients have no support for those protocols anyway. And it makes it substantially easier to expose and consume services that those clients can consume.

So it comes down to a tradeoff when you are putting together your solution architecture – are you going for reach and/or and open solution or are you going for richness in a closed solution? If you have a good architecture and have factored your real back end business logic into components that are not coupled to who their caller is, you can easily do both – call your logic from WCF services exposed to the clients that support those protocols, and call that same logic from services exposed through the ASP.NET Web API for reach to your more constrained client platforms.

One of the things that ASP.NET Web API supports is the ability to host in either IIS as part of the ASP.NET infrastructure, or to self-host in your own process. In the former case, it is important to realize that there is no WCF involved in message processing. It can use the WCF data contract serializers, but does not have to. However, when you are self-hosted, there is a thin layer at the bottom of the stack that is the WCF ServiceHost hosting infrastructure to get the message pushed into the Web API stack. But from there on, there is still no WCF channel stack in play.

ASP.NET Web API supports a number of other important capabilities for Web APIs and REST services including the ability to map resource Uris into handling methods, automatically convert and pass parameters and return types to methods in a strongly typed way or a message-focused way, the ability to support any format in the HTTP body messages, and the ability to support content negotiation. The ASP.NET Web API is also different from WCF in that it is config-less, you need no web.config or app.config code, and the configuration options you do have are done programmatically in the hosting environment. It can also be nearly attribute-less. It uses convention over configuration to minimize the amount of configuration and decorating of methods with attributes that is needed. It also has many extensibility hooks, so it is not limited from being extended in just about any way you need to. But out of the box, it is simple and focused on particular patterns.

Both WCF and ASP.NET Web API have their place. Think of it as if you had two kids that were into sports. One is the stereotype of a “super jock” – they can play football, baseball, soccer, tennis, surf, etc. The other kid is phenomenal at just one sport. Neither one can really be said to be more of an athlete than the other, they just have a different scope of focus. WCF is the super jock – any wire protocol, many semantic protocols, highly configurable and extensible. ASP.NET Web API is the really good athlete at one focused thing – being easy to define and expose and consume, while also facilitating doing things in a RESTful way.

I’ll be giving a talk on the Web API at the DevConnections Spring 2012 conference in Las Vegas. Keep your eyes on the IDesign events feed for more events and the articles feed for more articles on the Web API from IDesign architects in the future.

© 2012 IDesign, Inc. All rights reserved.