What's the difference between WCF Web API and ASP.NET Web API
Ive done a little more reading around this and found a few pages by MS people on this:
http://wcf.codeplex.com/wikipage?title=How%20to%20Migrate%20from%20WCF%20Web%20API%20to%20ASP.NET%20Web%20API :
The WCF Web API abstractions map to ASP.NET Web API roughly as follows
WCF Web API -> ASP.NET Web API
- Service -> Web API controller
- Operation -> Action
- Service contract -> Not applicable
- Endpoint -> Not applicable
- URI templates -> ASP.NET Routing
- Message handlers -> Same
- Formatters -> Same
- Operation handlers -> Filters, model binders
and http://wcf.codeplex.com/discussions/319671
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
From what I've learned, Microsoft did a little bit of naming confusion here.
I'm assuming you know what WCF is all about, this big framework built on top of XML to allow user to build distributed services with a wide variety of technologies (from SOAP to REST to MSMQ etc.).
It's hard as hell to use (for me at least) and requires a lot of bootstrap to have it working, and eventually they realized this and started providing some default configuration for simple http services (WCF REST starter kit anyone?). ASP.NET MVC was gaining momentum and some of the features it provided (automatic arguments matching for example) started to show up in WCF.
Now that's the situation:
Announcement: WCF Web API is now ASP.NET Web API! ASP.NET Web API released with ASP.NET MVC 4 Beta. The WCF Web API and WCF support for jQuery content on this site wll removed by the end of 2012.
http://wcf.codeplex.com/wikipage?title=Getting%20started:%20Building%20a%20simple%20web%20api
And that's better imho.
I'm quite sure it should be possible to host asp.net mvc4 webapi on top of WCF (if you ever need that), but i can't find documentation that can prove me right (or wrong).
UPDATE (can't fit as comment): Wait, there is a huge different between "moving a subset of communication technology from a library/framework to another" and "replace WCF". I personally think that WCF was designed for some kind of communication concept and it has a rather cool design, but the distributed computing is somewhat moving on to new (and simpler) solutions (look the feature-rich SOAP vs the lean e flexible REST, although many people still use REST in a RPC manner), and i think that this kind of programming patterns better fit into the MVC architecture than the WCF one. Effort was put on designing some simple way of building/consuming web services on top of WCF, but they eventually found out that it was not the right solution.
Not to mention that many developers now use ASP.NET MVC and want to do rest web services for their web app, messing with WCF is often overkill for these kind of things, and I've experienced that on my own skin.
I think that the routing mechanism is awesome and the right way to go, and if you look closely, they included part of it (with different names and types, but the pattern was there) in WCF. So yeah, i think that if MS don't dismiss that part of WCF WE should do it. To strictly answer, no, i don't think you'll ever find WebGet/WebInvoke in asp.net mvc*, it just don't fit in.
Yeah self-host is probably the only bit of WCF contained in ASP.NET MVC4 right now.
It looks like WCF itself is somehow dying or at least becoming much less important then it was supposed to be and because of that it also has much less development effort put into its feature set. New features in WCF itself are more cosmetic.
WCF was designed as transport / protocol independent way for inter process communication. Even the idea was independent abstraction it was mostly build on top of SOAP stack. When WCF 3.5 brought support for REST it was mostly hacked in because REST is all about transport dependency. Using transport independent API to support inter process communication which is done through directly using transport features appeared inconvenient. As result MS first released WCF Rest API Starter Kit which never reached RTM but it was preview of features which was later included in WCF 4 and finally in .NET 4.5 or WCF Web API. Because REST is transport dependent and currently used only with HTTP (even it is theoretically possible to use other transport protocol) the API was moved to .NET part which is more suitable for HTTP processing - to currently very popular ASP.NET MVC.
WCF Web API is replaced by ASP.NET Web API which takes features from WCF Web API and merges them with the features from ASPNet MVC. ASP.NET Web API is a new (02/2012) framework for building and consuming HTTP services and a platform for building RESTful service.
Although not in the original question it seems worth noting that WCF is alive and well and its REST support remains useful when you have existing SOAP (WS-*) services you must support but want to add REST to reach more clients.
Reference
- CodePlex: WCF Web API is now ASP.NET Web API
- CodePlex: Daniel Roth on the Future of WCF
- Chanel9: Dan Roth on the new ASP.NET Web API
The following excerpt found on this MSDN page summarizes this dilemma well.
Use WCF to create reliable, secure web services that accessible over a variety of transports. Use ASP.NET Web API to create HTTP-based services that are accessible from a wide variety of clients. Use ASP.NET Web API if you are creating and designing new REST-style services. Although WCF provides some support for writing REST-style services, the support for REST in ASP.NET Web API is more complete and all future REST feature improvements will be made in ASP.NET Web API. If you have an existing WCF service and you want to expose additional REST endpoints, use WCF and the WebHttpBinding.