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,
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.