What's the difference between WCF Web API and ASP.NET Web API

Question

I've done a bit of work in the past using WCF WebAPI and really liked a lot of its features, I'm just playing with ASP.NET Web API at the moment and it seems completely different (IE completely removed from WCF).

Does anyone know which features of WCF WebAPI are included in ASP.NET 4 Web API?

Solution 1

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

Solution 2

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.

Solution 3

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.

Solution 4

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

1. CodePlex: WCF Web API is now ASP.NET Web API
2. CodePlex: Daniel Roth on the Future of WCF
3. Chanel9: Dan Roth on the new ASP.NET Web API

Solution 5

Here is good article on Web Service, WCF and Web API http://goo.gl/T29A5B

Web Service

• Based on SOAP and return XML Data
• Support only HTTP protocol. It support only HTTP protocol.
• Consumed by client that able to understand xml SOAP Services.
• Can host on IIS. It can be hosted only on IIS.
• Easy to Learn and understand.

WCF

• Based on SOAP and return XML Data. SOAP is heavy compare then JSON and its overhead over network also.
• Enhanced version of web services support multiple protocols like TCP, HTTP, HTTPS, Named Pipes, MSMQ via configuration.
• More reliable when both client and server have .Net.
• Its implementation and configuration is complex
• Consumed by client that able to understand xml SOAP Services.
• Self-hosting, IIS and using windows services.

Web API (Web API 2.0)

• Design specifically for building HTTP Restful Services on .Net Framework.
• Web API easily readable and handy as JSON.
• Support all features of HTTP Like URls, Request/Response, Headers, Caching and Versioning.
• Web API support many HTTP Verbs like GET, POST, PUT, DELETE etc.
• Web API is stateless.
• Web API supports MVC features (controllers, action results, routing, filter, model binders, IOC container or dependency injection)
• Web API can be self-hosted, hosted with in the application and on IIS.
• OWIN (Open Web Interface for .NET) is used for self-Hosting.

View more solutions

Comments

[undefined]

Yeah from what i can tell MVC4 Web API is designed to be a direct replacement for WCF WebApi. But I'm not too sure how that works as it seems to be provided over ASP not WCF, which is a little weird. Is ASP supposed to replace WCF? Im also not too sure which bits of WCF WebAPI are included in the new product, ive noticed the test client isnt there yet, but i was also wondering about the differences in routing (and other areas), is ASP.Net routing supposed to replace the WebInvoke extensions for Wcf WebAPI or are they still there somewhere?

[undefined]

Im not too sure what you mean by "I'm quite sure it should be possible to host asp.net mvc4 webapi on top of WCF" they seem a bit mutually exclusive to me, do you mean 'Self Hosting'?

[undefined]

So basically what your saying is that the SOAP component of WCF still stands as WCF however the REST component has now moved to ASP.

[Teoman Soygul]

WCF was all about abstracting away HTTP, TCP, etc. REST stack on the other hand is all about utilizing HTTP so separating the two is an excellent move in the name of keeping WCF as a pure protocol neutral service stack.

[Darrel Miller]

Actually the naming is quite accurate. The WCF team members who were previously working on WCF Web API moved over to the ASP.Net team. There was overlap between WCF Web API and ASP.NET MVC and that was creating a confusing choice. MS fixed the problem. But look closer at Web API and note that some of the core classes reside in System.Net.Http. And listen to Brad Wilson's interview on Herding Code when he talks about the limitations with the current MVC framework.

[tugberk]

"It's hard as hell to use (for me at least) and requires a lot of bootstrap to have it working" totally right!

[WDRust]

@LukeMcGregor yes, it's kinda like this. I wonder now if they will strictly support the REST patterns used in MVC only for asp.net. This way, if I have to maintain a large set of API for my network application, i have to keep different codebases for my SOAP/MSMQ/whatever communication and REST. That cut the usefulness of wcf alot.

[WDRust]

DarrelMiller: yeah now it's ok, and that was surely necessary, i was just saying that doing this earlier would have been better. I think that building REST on top of WCF was a bad idea from the beginning, wasn't it?

[John Saunders]

-1: the "ASP.NET" web api is no reason to believe that WCF is dying or becoming less important. It's a reason to believe that the target market for REST services is not the target market for WCF.

[radu florescu]

WCF is a back-end service meanwhile WebApi is more of a front-end service

[John Saunders]

-1: "Bloated" is a nonsense word. Also, WCF does have REST support.

[Cheung]

I agree with @tilde. For sample usage like legacy web service thought Http, i think WebAPI is enough. WCF is over-kill.