web api的应用

 http://www.cnblogs.com/artech/p/web-api-sample.html


ASP.NET Web API不仅仅具有一个完全独立的消息处理管道，而且这个管道比为ASP.NET MVC设计的管道更为复杂，


功能也更为强大。虽然被命名为“ASP.NET Web API”，但是这个消息处理管道却是独立于ASP.NET平台的，这也是


为什么ASP.NET Web API支持多种寄宿方式的根源所在。[本文已经同步到《How ASP.NET Web API Works?》]


WebApi 表现为HttpController类型的Web API就定义在此项目中，它具有对Common(空的类库，仅定义了表示
联系人的数据类型而已）的项目引用


WebHost这是一个空的ASP.NET WEB 应用，它实现了针对ASP.NET WEB API的WEB HOST寄宿，该项目具有针对WebApi


的项目引用 


SelfHost 这是一个空的控制台应用，旨在模拟ASP.NET WEB API的寄宿模式，它同样具有针对webApi的项目引用。


WebApp 这是一个空的ASP.NET WEB应用，代表“联系人管理器”的网页就存在于该项目之中，至于具体的联系人管


理功能，自然通过以Ajax的形式调用Web API来完成


consoleApp  这是一个空的控制台应用，我们用它来模拟如何利用客户端代理来实现对Web API的远程调用，它具有
针对Common的项目的引用


。由于ASP.NET Web API默认实现了Action方法与HTTP方法的映射，所以方法名也体现了它们各自所能处理请求必须


采用的HTTP方法


虽然被命名为ASP.NET Web API，但是其核心的消息处理管道却是独立于ASP.NET平台的，所以我们可以对相同的Web 


API实施不同的寄宿方式。寄宿的本质就是利用一个具体的应用程序为Web API提供一个运行的环境，并最终解决“


请求的接收和响应的回复”问题。作为寄宿的一种主要形式，Web Host就是创建一个ASP.NET Web应用作为Web API


的宿主。


与ASP.NET MVC一样，如果采用Web Host的方式来寄宿Web API，ASP.NET自身的路由系统会成为接收请求的第一道屏


障。在将请求递交给ASP.NET Web API自己的消息处理管道之前，路由系统会解析出当前请求访问的目标


HttpController和Action的名称。我们需要做的就是根据需求注册相应的路由，这也是采用Web Host寄宿方式所需


的唯一操作。


映射


如果你了解ASP.NET MVC的路由注册，可能觉得奇怪：注册路由的模板中并没有表示目标Action的路由参数，ASP 


.NET Web API如何根据请求确定哪个Action方法应该被调用呢？答案其实很简单：它能根据请求采用HTTP方法来确


定目标Action方法。当然，在注册路由模板中提供代表Action名称的路由参数（{action}）也是支持的。


我们采用的浏览器为Chrome，获取的联系人列表总是表示为XML，这是为什么呢？在前面介绍REST的时候，我们曾经


提及一种旨在识别客户端期望的资源表示形式并被称为“内容协商”的机制，它可以根据请求携带的相关信息来判


断客户端所期望的响应资源表现形式。


对于ASP.NET Web API来说，它会优先利用请求报头“Accept”携带的媒体类型来确定响应内容采用的表现形式。如


下所示的是Chrome访问“http://localhost/webhost/api/contacts/001”发送请求的内容，它之所以会得到以XML


表示的响应是因为“Accept”报头指定的媒体类型列表中只有“application/xml”被ASP.NET Web API支持。如果


我们采用IE，请求的“Accept”报头将携带不同的媒体类型列表，我们实际上会得到以JSON格式表示的响应结果。


   1: GET http://localhost/webhost/api/contacts/001 HTTP/1.1


   2: Host: localhost


   3: Connection: keep-alive


   4: Cache-Control: max-age=0


   5: Accept: text/html,application/xhtml+xml,application/xml ;q=0.9,image/webp,*/*;q=0.8


   6: User-Agent: Mozilla/5.0 (Windows NT 6.1) AppleWebKit/537.36 (KHTML, like Gecko) 


Chrome/31.0.1650.63 Safari/537.36


   7: Accept-Encoding: gzip,deflate,sdch


   8: Accept-Language: en-US,en;q=0.8,zh-CN;q=0.6,zh-TW;q=0.4


为了进一步验证并演示ASP.NET Web API的内容协商机制，我们现在改用Fiddler来发送调用Web API的HTTP请求。如


左图所示，我们利用Fiddler发送了一个针对目标地址“http://localhost/webhost/api/contacts/001”的HTTP-


GET请求，并添加了一个值为“application/json”的“Accept”报头，请求发送之后确实得到了以JSON格式表示的


联系人列表。


在定义ContactsController的时候，我们严格按照RESTful Web API关于“使用标准的HTTP方法”的指导方针，分别


采用GET、POST、PUT和DELETE作为获取、创建、修改和删除联系人的操作所支持的HTTP方法。但是IIS在默认情况下


并不提供针对 PUT和DELETE请求的支持。


如右图所示，我们利用Fiddler发送了一个针对地址“http://localhost/webhost/api/contacts/001”的HTTP-


DELETE请求，旨在删除ID为“001”的联系人。但是遗憾的是，我们得到了一个状态为“405，Method Not Allowed


”的响应，意味着服务端并不支持HTTP-DELETE方法。


IIS拒绝PUT和DELETE请求是由默认注册的一个名为“WebDAVModule”的自定义HttpModule导致的。WebDAV的全称为


“Web-based Distributed Authoring and Versioning”，它是一个在多用户之间辅助协同编辑和管理在线文档的


HTTP扩展。该扩展使应用程序可以直接将文件写到 Web Server 上，同时支持文件的加锁和版本控制。


微软是推动WebDAV成为一个标准的主导力量，它自己利用自定义的HttpModule实现了IIS针对WebDAV的支持。但是这


个默认注册（注册名称为“WebDAVModule”）会拒绝HTTP方法为PUT和DELETE的请求，如果我们的站点不需要提供针


对WebDAV的支持，解决这个问题最为直接的方式就是利用如下的配置将注册的HttpModule移除。


   1: <configuration>


   2:   ...


   3:   <system.webServer>


   4:     <modules runAllManagedModulesForAllRequests="true">


   5:       <remove name="WebDAVModule" />


   6:     </modules>


   7:   </system.webServer>


   8: </configuration>