在最近发布的Visual Studio 2012及.NET 4.5中， 微软正式推出新的网络服务框架ASP.NET Web API。作为ASP.NET MVC 4的一部分，ASP.NET Web API这套开源框架的设计目的是简化RESTful服务的开发和使用。
在“Where does ASP.NET Web API Fit?”这篇博文中, West Wind Technologies的 Rick Strahl 解析了ASP.NET Web API的目标与优势。
ASP.NET Web API 与之前的内建HTTP服务解决方案的不同之处在于，它一开始就是围绕HTTP协议及其消息语义构建起来的。与WCF REST或ASP.NET AJAX加ASMX相比，它不是对现有框架的增强，而是一个全新的平台。新的ASP.NET Web API的优势在于它汇集了之前各平台的各种最佳特性，结合为一个全面而不臃肿的HTTP平台。这套Web API基于ASP.NET，又借用了很多ASP.NET MVC的概念，应该很容易被ASP.NET的开发者适应和熟悉。
Strahl 指出ASP.NET Web 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
微软现有的Web服务框架叫做Windows Communication Foundation（ WCF），它利用TCP、HTTP、MSMQ等传输协议构建“契约先行”的服务。WCF最初为基于SOAP的服务而设计，首先支持的是WS-*功能，但后来添加了少量迎合REST的功能。按照Ido Flatow在一篇Code Project文章中的描述，ASP.NET Web API一开始也归在WCF框架旗下，但最终被移交到ASP.NET团队。
随着时间流逝，WCF Web API为了让WCF适配到”原生”HTTP世界，遇到了很多困难。因为WCF主要是为基于SOAP的XML消息设计的，为了让Web API成为WCF一部分，需要动的手术实在有点大（至少Web API的开发者们给了我这样的印象）。另一方面，ASP.NET MVC的基础设施既能优雅地处理HTTP请求和响应，又能轻松创建各种控制器，好像是创建这种新类型服务的合适途径。
WCF在最新的.NET 4.5中依然健在，Flatow给出了一些在WCF和ASP.NET Web API之间做出选择的标准。
- 如果想让服务支持特殊场景，如单向消息传递、消息队列、双向通信等等，最好选择WCF。
- 如果想让服务优先使用快速传输通道，如TCP、Named Pipes，甚至UDP（在WCF 4.5中），然后在所有其他传输都不可用的时候支持HTTP，那么最好选择WCF，并且把SOAP和WebHttp两种绑定都用上。
- 如果服务是建立在HTTP之上的面向资源的服务，需要发挥HTTP的全部功能，如 定义浏览器的缓存控制，用ETags做版本与并发，传送图像、文档、HTML页面等多种类型的内容，在响应中用URI模板去包含Task URIs，那么新的Web API是最好的选择。
- 如果服务是多目标环境的，既可作为面向资源的服务走HTTP通道，又可作为RPC风格的SOAP服务走TCP通道——先跟我谈谈吧，我会给你一些指点。
ASP.NET Web API已经包含在Visual Studio 2012中，Visual Studio 2010用户可单独下载。需要上手指导的开发者可以在该团队的Codeplex网站上找到很多示例项目。
查看英文原文：Microsoft Release New REST API Framework as Part of .NET 4.5