ASP.NET Web API 与之前的内建HTTP服务解决方案的不同之处在于，它一开始就是围绕HTTP协议及其消息语义构建起来的。与WCF REST或ASP.NET AJAX加ASMX相比，它不是对现有框架的增强，而是一个全新的平台。新的ASP.NET Web API的优势在于它汇集了之前各平台的各种最佳特性，结合为一个全面而不臃肿的HTTP平台。
微软已经有了一个的Web服务框架叫做Windows Communication Foundation（ WCF），它利用TCP、HTTP、MSMQ等传输协议构建“契约先行”的服务。WCF最初为基于SOAP的服务而设计，首先支持的是WS-*功能，但后来添加了少量迎合REST的功能。在WCF 4.5也有很大的增强。
随着时间流逝，WCF Web API为了让WCF适配到”原生”HTTP世界，遇到了很多困难。因为WCF主要是为基于SOAP的XML消息设计的，为了让Web API成为WCF一部分，需要动的手术实在有点大（至少Web API的开发者们给了我这样的印象），是基于RPC风格的API。另一方面，ASP.NET MVC的基础设施既能优雅地处理HTTP请求和响应，又能轻松创建各种控制器，好像是创建这种新类型服务的合适途径。
- 支持URL路由，透过用户熟悉的MVC风格路由语义，生成干净的URL
- 根据Accept标头对请求和响应的序列化形式进行内容协商（Content Negotiation）
- 支持大量输出格式，包括JSON、XML、ATOM等
- 默认对REST语义有完善支持，同时又不强制限定必须使用REST语义
- 易于扩展的Formatter机制，支持添加新的输入/输出类型
- 可通过HttpResponseMessage类、HttpRequestMessage类和强类型枚举来描述大量的HTTP操作，提供对更高级的HTTP特性的深度支持
- 基于惯例的设计引导用户按HTTP Services的正确方式行事
- Formatters和Filters延续了MVC的扩展模型，具备出色的扩展能力
- 用于非Web程序时，可以脱离IIS运行（Self-hostable）
- 具备可测试性，测试机制的设计类似于MVC
现在我们拥有了2个服务框架，一个基于RPC机制的WCF和一个基于HTTP的ASP.NET Web Api。在我们的开发实践中如何进行选择呢？ 可以参照知名互联网企业，无论是google，facebook,baidu,新浪还是腾讯。他们对外开放的接口都是基于Http的Web API，在服务内部框架都是基于SOA架构设计的，通讯机制都是采用RPC机制的，例如Google Protocol Buffers ，Facebook thift。 我们完全也可以这样搭配，在内部通讯采用WCF + Protobuf-NET，参看《WCF服务上应用protobuf》，对外的服务采用ASP.NET WEB API。WCF的 TCP、Named Pipes，甚至UDP（在WCF 4.5中）绑定的性能要比HTTP强很多倍，这里有一个几年前的微软的测试报告《WCF 性能基准报告》，对外提供的服务采用Web API同时也是一个业界标准问题，用WebAPI就很容易的跨越ios，android，wp等移动终端平台，同时有很成熟的OAuth 解决安全问题。