What's the difference between WCF Web API and

问题:

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?

回答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

回答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.

回答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.

回答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

回答5:

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.

回答6:

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.

回答7:

ASP.net web api is lightweight and REST support inbuilt. It is more suitable for mobile applications.WCF is bloated with more options . It depends on the complexity of the system to select one of these.