WCF Web API和ASP.NET Web API有什么区别？
我在过去使用WCF WebAPI做了一些工作，并且非常喜欢它的许多特性，现在我只是在使用ASP.NET Web API，看起来完全不同（IE完全从WCF中删除了）。
有谁知道WCF WebAPI的哪些function包含在ASP.NET 4 Web API中？
我已经做了一些更多的阅读这个，并find了MS的人几页在这：
WCF Web API抽象概述如下，映射到ASP.NET Web API
WCF Web API – > ASP.NET Web API
- 服务 – > Web API控制器
- 操作 – >操作
- 服务合同 – >不适用
- 端点 – >不适用
- URI模板 – > ASP.NET路由
- 消息处理程序 – >相同
- 格式化程序 – >相同
- 操作处理程序 – >filter，模型活页夹
和http://wcf.codeplex.com/discussions/319671
集成堆栈支持以下function：
- 现代HTTP编程模型
- 完全支持ASP.NET路由
- 内容协商和自定义格式化程序
- 模型绑定和validation
- filter
- 查询组成
- 易于unit testing
- 通过DependencyResolver改进控制反转（IoC）
- 基于代码的configuration
- 自主机
从我所了解到的情况来看，微软在这里做了一些命名混淆。
我假设你知道WCF是什么，这个基于XML的大框架允许用户使用各种各样的技术（从SOAP到REST到MSMQ等）构build分布式服务。
（至less对我来说）很难，而且需要大量的bootstrap才能运行，最终他们意识到了这一点，并开始为简单的http服务（WCF REST入门套件？）提供一些默认configuration。 ASP.NET MVC越来越stream行，它提供的一些function（例如自动参数匹配）开始出现在WCF中。
现在就是这样的情况：
公告：WCF Web API现在是ASP.NET Web API！ 随ASP.NET MVC 4 Beta发布的ASP.NET Web API 2012年底，WCF Web API和WCF支持jQuery内容。
http://wcf.codeplex.com/wikipage?title=Getting%20started:%20Building%20a%20simple%20web%20api
这更好，恕我直言。
我很确定应该可以在WCF之上托pipeasp.net mvc4 webapi（如果你需要的话），但是我找不到可以certificate我是正确（或错误）的文档。
更新 （不能适合作为评论）：等等，“将通信技术的一个子集从库/框架移动到另一个”和“replaceWCF”有很大的不同。 我个人认为WCF是为某种通信概念devise的，它有一个相当酷的devise，但是分布式计算有点转向新的（更简单的）解决scheme（看看function丰富的SOAP与精益灵活的REST，尽pipe许多人仍然以RPC方式使用REST），我认为这种编程模式比WCF更适合MVC体系结构。 努力devise了一些在WCF之上构build/使用Web服务的简单方法，但是他们最终发现这不是正确的解决scheme。
更不用说现在很多开发人员使用ASP.NET MVC，并且想为他们的web应用程序完成其他的web服务，而使用WCF搞乱这些东西往往是过分的，我已经在自己的皮肤上体验过了。
我认为路由机制是非常好的，也是正确的path，如果仔细观察，他们会在WCF中包含部分（不同的名称和types，但模式在那里）。 所以是的，我认为如果MS不排除WCF的那部分我们应该这样做。 要严格回答，不，我不认为你会发现asp.net mvc *中的WebGet / WebInvoke，它只是不适合。
自主主机可能是ASP.NET MVC4中包含的唯一一个WCF。
看起来WCF本身在某种程度上正在死亡，或者至less变得不那么重要，因为它本身的function集也没有太多的开发工作。 WCF中的新function更美观。
WCF被devise为独立于传输/协议的进程间通信方式。 即使这个想法是独立的抽象，它主要build立在SOAP堆栈之上。 当WCF 3.5带来对REST的支持时，它大部分都是黑客入侵的，因为REST都是关于传输依赖的。 使用传输独立API来支持通过直接使用传输特征完成的进程间通信似乎是不方便的。 因此，MS首先发布了永远不会到达RTM的WCF Rest API入门套件，但它是后来被包含在WCF 4中，最后在.NET 4.5或WCF Web API中包含的function的预览版本。 由于REST依赖于传输，目前仅与HTTP一起使用（即使理论上可能使用其他传输协议），API也被移到了更适合HTTP处理的.NET部分 – 到当前非常stream行的ASP.NET MVC。
WCF Web API被ASP.NET Web API取代，该Web API从WCF Web API获取function，并将其与ASPNet MVC的function合并。 ASP.NET Web API是用于构build和使用HTTP服务的新（02/2012）框架，也是构buildRESTful服务的平台。
虽然不是原来的问题，但值得注意的是WCF仍然活着，当你有必须支持的现有的SOAP（WS- *）服务，但是想要添加REST以接触更多的客户端时，它的REST支持仍然有用。
参考
- CodePlex：WCF Web API现在是ASP.NET Web API
- CodePlex：Daniel Roth关于WCF的未来
- Chanel9：Dan Roth在新的ASP.NET Web API上
以下在MSDN页面上find的摘录很好地总结了这种困境。
使用WCF创build可通过各种传输访问的可靠，安全的Web服务。 使用ASP.NET Web API创build可从各种客户端访问的基于HTTP的服务。 如果您正在创build和devise新的REST风格的服务，请使用ASP.NET Web API。 尽pipeWCF为编写REST风格的服务提供了一些支持，但对ASP.NET Web API中对REST的支持更为完善，未来RESTfunction的所有改进都将在ASP.NET Web API中进行。 如果您有现有的WCF服务，并且想要公开其他REST端点，请使用WCF和WebHttpBinding。
这里是关于Web服务，WCF和Web API的好文章http://goo.gl/T29A5B
networking服务
- 基于SOAP并返回XML数据
- 仅支持HTTP协议。 它只支持HTTP协议。
- 由客户端消费，能够理解XML SOAP服务。
- 可以在IIS上托pipe。 它只能在IIS上托pipe。
- 易于学习和理解。
WCF
- 基于SOAP并返回XML数据。 SOAP比JSON及其在networking上的开销更重。
- Web服务的增强版本通过configuration支持多种协议，如TCP，HTTP，HTTPS，命名pipe道，MSMQ。
- 当客户端和服务器都有.Net时更可靠。
- 其实施和configuration是复杂的
- 由客户端消费，能够理解XML SOAP服务。
- 自托pipe，IIS和使用Windows服务。
Web API（Web API 2.0）
- 专门为在.Net Framework上构buildHTTP Restful Services而devise。
- Web API易于阅读并且像JSON一样方便。
- 支持HTTP的所有function如URls，Request / Response，Headers，Caching和Versioning。
- Web API支持许多HTTP动词，如GET，POST，PUT，DELETE等
- Web API是无状态的。
- Web API支持MVCfunction（控制器，操作结果，路由，filter，模型绑定器，IOC容器或dependency injection）
- Web API可以自行托pipe，在应用程序和IIS上托pipe。
- OWIN（.NET的Open Web Interface）用于自托pipe。
ASP.net web api是轻量级的，支持REST内置。 它更适合移动应用程序.WCF拥有更多的选项。 这取决于系统的复杂性来select其中之一。
