我一直在研究WebAPI，并且非常喜欢我所看到的。
有没有理由不使用WebAPI？如果是这样，在什么情况下？
我最初认为在跨平台的SOA架构中，WebAPI可能不尽如人意，但是我阅读的文章越多，我越发现WebAPI几乎在每个现实场景中都可能胜过WCF。看起来你可以使用WebAPI for android，ios等而不仅仅是.Net;甚至性能表明WCF REST最慢。 http://weblog.west-wind.com/posts/2012/Sep/04/ASPNET-Frameworks-and-Raw-Throughput-Performance
WCF还有一个“显而易见”的理由吗？
答案 0 :(得分：13)
每当您控制使用者和提供者端点（例如后端服务到服务通信）时，您应该使用WCF（或套接字）来提高功能和性能。通过WCF托管服务然后共享二进制合同意味着客户端和服务器之间100％保证匹配，编译器检查和类型安全（de）序列化。
如果您还拥有完整的CI，那么除了可以消除发布不匹配合同的二进制文件的风险之外。 Web API序列化更加宽容，因此验证和测试更加复杂（客户端可以发送数据服务器不期望，服务器可以发送数据客户端不期望。）WCF还支持合同版本控制和扩展数据，这样只允许中间服务知道V1合同仍然可以接受并转发到V2或更晚的消息，同时保留了解V2或以后合同的服务的所有数据！）
WebAPI主要用于实现基于HTTP的服务，而且挫折度最小，因此，WebAPI在很大程度上依赖于asp.net HTTP Web Stack来运行（而WCF及其基础不支持，事实上，一些WebAPI功能直接依赖在WCF上..例如，通过WebAPI公开OData提要。）
与Web API端点类似，WCF端点可以配置为根据需要通过HTTP提供访问（在其他协议和技术中，如安全命名管道，MSMQ，UDP，TCP等）.WCF也是可扩展的，并且不在它为双工，双向和可靠消息传递提供传输实现，它使用令牌，证书，基本身份验证凭据等提供传输级别和消息级别身份验证。对服务发现，订阅，广播等有额外的支持（不可否认，WebAPI提供了一些重叠，但没有相同的控制级别。）
WCF不仅支持所有这一切，它还具有高度可配置性，允许您通过配置文件和代码在可用传输的MOST，格式化/序列化，安全性，实例化，生命周期和其他服务设置之间进行混合和匹配。
现在将两个中间层移到同一台机器上？切换到命名管道。将服务器从.net交换到PHP？没问题，更改绑定配置使用net.tcp来使用soap。 WebAPI停止的地方，WCF继续。
然而，与任何技术一样，WCF只会让您的开发人员对网络和基础架构有所了解。放在平庸或不情愿的手中，你将得到一个完整的混乱，无法执行。 WebAPI有点简单，甚至初学程序员也可以在几分钟内使用它，并且通常可以成功完成任务。
2C