WCF Web API is now ASP.NET Web API!

We are happy to announce that ASP.NET Web API has now shipped with
ASP.NET MVC 4 Beta!

ASP.NET Web API represents the joint efforts of the WCF and ASP.NET teams to create an integrated web API framework. You can
get the bits and find articles, tutorials, samples and videos on the new
ASP.NET Web API home page. We have also setup a
Web API forum on the ASP.NET site where we will monitor customer questions and discussions.

Some history

For several years now the WCF team has been working on adding support for REST. This resulted in several flavors of REST support in WCF: WCF WebHTTP, WCF REST Starter Kit, and then finally WCF Web API. In parallel the ASP.NET MVC team shipped support for
building basic web APIs by returning JSON data from a controller. Having multiple ways to do REST at Microsoft was confusing and forced our customers to choose between two partial solutions. So, several months ago the WCF and ASP.NET teams were merged together
and tasked with creating a single integrated web API framework. The result is ASP.NET Web API.

What is ASP.NET Web API?

ASP.NET Web API is a framework for building and consuming HTTP services that can reach a broad range of clients including browsers and mobile devices. It’s also a great platform for building RESTful services. ASP.NET Web API takes the best features
from WCF Web API and merges them with the best features from MVC.

The integrated stack supports the following features:

Modern HTTP programming model

Full support for ASP.NET Routing

Content negotiation and custom formatters

Model binding and validation

Filters

Query composition

Easy to unit test

Improved Inversion of Control (IoC) via DependencyResolver

Code-based configuration

Self-host

What does this mean for WCF Web API?

ASP.NET Web API is effectively the next version of WCF Web API. There will not be a separate release for WCF Web API and we will retire all WCF Web API content by the end of the year. Please post all future discussions to the new
ASP.NET Web API forum.

Why change the name?

Web APIs have a foot in two worlds: the world of service orientation and the World Wide Web. We decided to align ASP.NET Web API with the rest of the Microsoft web platform, so we went with the brand that communicates this alignment. From a technical perspective
we also decided to go with a new HTTP specific dispatcher instead of trying to carry forward the WCF dispatcher, so there is virtually no WCF code in the new stack.

Does this mean I have to host my web APIs in IIS?

You can continue to self-host your web APIs in your own processes just like you could with WCF. ASP.NET Web API is at its core a light-weight
HTTP message handler pipeline that is
host independent. Our current self-host support is actually based on the WCF HTTP transport, but you can host ASP.NET Web API on any HTTP host of your choosing.

How do I migrate to my WCF Web API code to ASP.NET Web API?

We have started putting together some migration guidance
here and we will flesh out the guidance in the upcoming weeks.

For the ASP.NET Web API Beta we focused on getting the right framework runtime in place. Unfortunately, this meant that we weren’t able to get the test client and help page support ported onto the new stack in time for Beta. We are working on these
features and we expect to ship them before the final ASP.NET Web API release.

Will the source code be made available?

We will publish the source code in the upcoming weeks.

Thank you for your support and please let us know if you have any questions or concerns!

I don't understand from this post what's the advantage of having Web APIs on ASP.NET instead of WCF ... illumination please?

How about SOA with REST? ASP.NET does not have a "service" concept and so the whole infrastructure associated with management of services is missing. What is the story of developing REST services with WCF that can be consumed by both JSON and XML clients?

I actually don't see why I'd want to develop my APIs on ASP.NET infrastructure - exposing APIs to the world is a service-oriented "thingy"; I will never have web pages rendered by the same project as the one which implements the APIs.