UPDATE （不能作为评论）：等等，"moving a subset of communication technology from a library/framework to another"和"replace WCF"之间有很大的不同 . 我个人认为WCF是为某种通信概念而设计的，它有一个相当酷的设计，但分布式计算有点转向新的（和更简单的）解决方案（看看功能丰富的SOAP与精益的灵活REST，虽然很多人仍然以RPC方式使用REST），我认为这种编程模式比WCF更适合MVC架构 . 努力设计了一些在WCF之上构建/使用Web服务的简单方法，但他们最终发现它不是正确的解决方案 .
使用WCF创建可通过各种传输访问的可靠，安全的Web服务 . 使用ASP.NET Web API创建可从各种客户端访问的基于HTTP的服务 . 如果要创建和设计新的REST样式的服务，请使用ASP.NET Web API . 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. 如果您有现有的WCF服务，并且希望公开其他REST endpoints ，请使用WCF和WebHttpBinding .
7 回答
我已经做了一些阅读，并在MS上发现了几页：
http://wcf.codeplex.com/wikipage?title=How%20to%20Migrate%20from%20WCF%20Web%20API%20to%20ASP.NET%20Web%20API：
WCF Web API抽象映射到ASP.NET Web API大致如下
WCF Web API -> ASP.NET Web API
服务 - > Web API控制器
操作 - >操作
服务 Contract - >不适用
endpoints - >不适用
URI模板 - > ASP.NET路由
消息处理程序 - >相同
格式化程序 - >相同
操作处理程序 - >过滤器，模型 Binders
和http://wcf.codeplex.com/discussions/319671
集成堆栈支持以下功能：
现代HTTP编程模型
完全支持ASP.NET路由
内容协商和自定义格式化程序
模型绑定和验证
过滤器
查询构成
易于单元测试
通过DependencyResolver改进了控制反转（IoC）
基于代码的配置
自我主持人
从我所学到的，微软在这里做了一点点混淆 .
我假设你知道什么是WCF，这个基于XML的大框架允许用户使用各种技术（从SOAP到REST到MSMQ等）构建分布式服务 .
这对我来说很难（至少对我而言）并且需要大量的引导来使它工作，最终他们意识到这一点并开始为简单的http服务提供一些默认配置（任何人都可以使用WCF REST入门套件？） . ASP.NET MVC正在获得动力，它提供的一些功能（例如自动参数匹配）开始出现在WCF中 .
现在情况就是这样：
http://wcf.codeplex.com/wikipage?title=Getting%20started:%20Building%20a%20simple%20web%20api
那是更好的imho .
我很确定应该可以在WCF之上托管asp.net mvc4 webapi（如果你需要的话），但我找不到可以证明我正确（或错误）的文档 .
UPDATE （不能作为评论）：等等，"moving a subset of communication technology from a library/framework to another"和"replace WCF"之间有很大的不同 . 我个人认为WCF是为某种通信概念而设计的，它有一个相当酷的设计，但分布式计算有点转向新的（和更简单的）解决方案（看看功能丰富的SOAP与精益的灵活REST，虽然很多人仍然以RPC方式使用REST），我认为这种编程模式比WCF更适合MVC架构 . 努力设计了一些在WCF之上构建/使用Web服务的简单方法，但他们最终发现它不是正确的解决方案 .
更不用说许多开发人员现在使用ASP.NET MVC并希望为他们的Web应用程序做休息Web服务，弄乱WCF对于这些事情来说往往有些过分，而且我在自己的皮肤上经历过这种情况 .
我认为路由机制很棒，也是正确的方法，如果仔细观察，它们会在WCF中包含部分内容（具有不同的名称和类型，但模式在那里） . 所以，是的，我认为如果MS不解雇那部分WCF WE 应该这样做 . 要严格回答，不，我不会在asp.net mvc *中找到WebGet / WebInvoke，它只是不适合 .
是的自主机可能是现在ASP.NET MVC4中包含的WCF的唯一位置 .
看起来WCF本身在某种程度上正在死亡，或者至少变得不那么重要，因为它应该是它的功能集中的开发工作量也少得多 . New features in WCF本身更具美感 .
WCF被设计为用于进程间通信的独立于传输/协议的方式 . 即使这个想法是独立的抽象，它主要 Build 在SOAP堆栈之上 . 当WCF 3.5为REST提供支持时，它主要被黑客入侵，因为REST完全是关于传输依赖性的 . 使用传输独立API来支持通过直接使用传输功能完成的进程间通信显得不方便 . 结果MS首次发布了从未到达RTM的WCF Rest API入门套件是功能的预览，后来包含在WCF 4中，最后包含在.NET 4.5或WCF Web API中 . 因为REST依赖于传输并且目前仅用于HTTP（即使理论上可以使用其他传输协议），API也被移动到更适合HTTP处理的.NET部分 - 当前非常流行的ASP.NET MVC .
WCF Web API由ASP.NET Web API取代，后者从WCF Web API获取功能并将它们与ASPNet MVC中的功能合并 . ASP.NET Web API是用于构建和使用HTTP服务的新（02/2012）框架，以及用于构建RESTful服务的平台 .
虽然不在最初的问题中，但值得注意的是WCF仍然存在并且当您拥有必须支持的现有SOAP（WS- *）服务但其希望添加REST以接触更多客户端时，其REST支持仍然有用 .
参考
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
在this MSDN page上发现的以下摘录很好地总结了这种困境 .
使用WCF创建可通过各种传输访问的可靠，安全的Web服务 . 使用ASP.NET Web API创建可从各种客户端访问的基于HTTP的服务 . 如果要创建和设计新的REST样式的服务，请使用ASP.NET Web API . 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. 如果您有现有的WCF服务，并且希望公开其他REST endpoints ，请使用WCF和WebHttpBinding .
这是关于Web服务，WCF和Web API的好文章http://goo.gl/T29A5B
Web Service
基于SOAP并返回XML数据
仅支持HTTP协议 . 它仅支持HTTP协议 .
由能够理解xml SOAP服务的客户端使用 .
可以在IIS上托管 . 它只能在IIS上托管 .
易于学习和理解 .
WCF
基于SOAP并返回XML数据 . 与JSON及其在网络上的开销相比，SOAP比较重要 .
增强版Web服务通过配置支持多种协议，如TCP，HTTP，HTTPS，命名管道，MSMQ .
当客户端和服务器都有.Net时更可靠 .
它的实现和配置很复杂
由能够理解xml SOAP服务的客户端使用 .
自托管，IIS和使用Windows服务 .
Web API (Web API 2.0)
专门用于在.Net Framework上构建HTTP Restful Services .
Web API易于阅读并且像JSON一样方便 .
支持HTTP的所有功能，如URls，请求/响应，标头，缓存和版本控制 .
Web API支持许多HTTP动词，如GET，POST，PUT，DELETE等 .
Web API是无状态的 .
Web API支持MVC功能（控制器，操作结果，路由，过滤器，模型 Binders ，IOC容器或依赖注入）
Web API可以自托管，在应用程序和IIS上托管 .
OWIN（用于.NET的Open Web Interface）用于自托管 .
ASP.net web api是轻量级的，内置REST支持 . 它更适合移动应用程序.WCF臃肿，有更多选项 . 它取决于系统的复杂性来选择其中之一 .