ASP.NET Web API是如何根据请求选择Action的?[下篇]

再《上篇》中我们简单介绍了用于实现Action选择机制的HttpActionSelector,接下来我们来讨论本章最为核心的内容:ASP.NET Web API如何利用HttpActionSelector(以默认的使用的ApiControllerActionSelector为例)在目标HttpController成功激活之后如何从中选择出匹配的Action方法来处理当前的请求。[本文已经同步到《How ASP.NET Web API Works?》]

目录 
候选的Action列表 
针对HttpRouteData中的Action名称进行筛选 
针对支持的HTTP方法进行筛选 
针对查询字符串和路由变量进行筛选 
针对ActionMethodSelector进行筛选 
异常处理

候选的Action列表

为了便于理解,我们通过一个具体的例子来实现在ApiControllerActionSelector的SelectAction方法中的Action选择策略。我们假设在一个ASP.NET Web API应用中定义了如上一个继承自ApiController的DemoController。

   1: public class DemoController : ApiController
   2: {
   3:     //无参数
   4:     [NonAction]
   5:     public string Get()
   6:     {
   7:         return "DemoController.Get()";
   8:     }
   9:     [HttpGet]
  10:     [ActionName("Get")]
  11:     public string Retrieve()
  12:     {
  13:         return "DemoController.Retrieve()";
  14:     }
  15:  
  16:     //一个参数
  17:     public string Get(string x)
  18:     {
  19:         return "DemoController.Get(string x)";
  20:     }
  21:  
  22:     //两个参数
  23:     public string Get(string x, string y)
  24:     {
  25:         return "DemoController.Get(string x, string y)";
  26:     }
  27:     public string Get(int x, int y)
  28:     {
  29:         return "DemoController.Get(int x, int y)";
  30:     }
  31:  
  32:     //Put, Post & Delete
  33:     public string Put()
  34:     {
  35:         return "DemoController.Put()";
  36:     }
  37:     public string Post()
  38:     {
  39:         return "DemoController.Post()";
  40:     }
  41:     public string Delete()
  42:     {
  43:         return "DemoController.Delete()";
  44:     }
  45: }

DemoController一共定义了8个Action方法,它们均返回表示各自方法签名的字符串。前面两个方法Get和Retrieve不具有参数,Retrieve方法上应用了两个特性:HttpGetAttribute特性使之支持HTTP-GET请求,ActionNameAttribute将Action名称设置为“Get”。第3个Get方法具有一个字符串类型的参数x。第4和第5个Get方法均具有两个同名的参数x和y。除了这5个基于HTTP-GET请求的Action方法之外,我们还针对HTTP-PUT、HTTP-POST和HTTP-DELETE定义了3个对应的Action方法。我们将这8个Action方法和自己支持的HTTP方法列在如下所示的表格中。

假设我们直接采用创建ASP.NET Web API项目默认提供的路由注册,相关的代码如下所示。接下来我们采用不同的URL对这个DemoController进行访问,并分析ApiControllerActionSelector针对每一个具体的请求是如何将目标Action方法筛选出来的。

   1: public static class WebApiConfig
   2: {
   3:     public static void Register(HttpConfiguration config)
   4:     {
   5:         config.Routes.MapHttpRoute(
   6:             name            : "DefaultApi",
   7:             routeTemplate   : "api/{controller}/{id}",
   8:             defaults        : new { id = RouteParameter.Optional }
   9:         );
  10:     }
  11: }

针对HttpRouteData中的Action名称进行筛选

我们知道HttpActionSelector具有两个基本方法,GetActionMapping返回一个描述定义在目标HttpController中所有Action方法的HttpActionDescriptor与Action名称的映射。具体来说,该方法返回的是一个ILookup<string, HttpActionDescriptor>对象,它具有如上表所示的结构。SelectAction方法将这个映射表作为最初的候选HttpActionDescriptor列表,并通过多轮筛选最终得到用于处理当前请求的那一个。

ApiControllerActionSelector针对请求提供的Action名称进行第一轮筛选。具体来说,它先从指定的HttpControllerContext中提取用于封装路由数据的HttpRouteData对象,如果其中包含目标Action的名称(对应条目的Key为“action”),它会从候选项中筛选出Action名称与之匹配的HttpActionDescriptor列表。反之,如果HttpRouteData中并不包含目标Action的名称,此项筛选工作将会忽略。

对于我们给出的这个例子来说,由于注册路由时并不曾在URL模板中定义针对Action名称的变量,所以生成的HttpRouteData中是不会包含目标Action名称的。

   1: public static class WebApiConfig
   2: {
   3:     public static void Register(HttpConfiguration config)
   4:     {
   5:  
   6:         config.Routes.MapHttpRoute(
   7:             name            : "DefaultApi",
   8:             routeTemplate   : "api/{controller}/{action}/{id}",
   9:             defaults        : new { id = RouteParameter.Optional }
  10:         );
  11:     }
  12: }

如果我们按照如上的方式让注册路由的URL模板包含一个针对目标Action名称的变量“{action}”,针对一个URL为“/api/contacts/get”的请求,ASP.NET Web API 的路由系统生成的HttpRouteData将会包含目标Action的名称“get”,那么如右图所示的5个同名的Action会率先被筛选出来。

针对支持的HTTP方法进行筛选

ApiControllerActionSelector进行的第2轮筛选工作是针对候选Action所支持的HTTP方法。具体来说,它通过候选HttpActionDescriptor对象的SupportedHttpMethods属性得到对应Action支持的HTTP方法列表,如果此列表包含当前请求的HTTP方法,那么此HttpActionDescriptor会被筛选出来。

对于定义在DemoController中的8个Action方法来说,如果请求采用的HTTP方法为HTTP-GET,那么如右图所示的5个唯一支持HTTP-GET请求的Action会被筛选出来;如果当前接收的是分别是一个HTTP-PUT、HTTP-POST或者HTTP-DELETE请求,那么与之对应的Action方法Put、Post和Delete会被筛选出来。

针对查询字符串和路由变量进行筛选

绑定到目标Action方法上的部分参数(参数类型支持源自字符串的类型转换)值来源于请求的URL,具体来说可以源自URL的路径,也可以源自URL的查询字符串。对于前者,其值一般会转换成路由变量被添加到路由系统生成的HttpRouteData中。第三轮筛选工作就是针对请求URL的查询字符串进行的。

一个Action方法能够正常执行,其前提是方法的参数值能够正常绑定。对于调用者来说,它发送的请求中必须提供执行目标方法所需的参数值。针对众多候选Action来说,如果其参数值应该由请求URL的查询字符串或者生成HttpRouteData来提供,能够被选择用于处理某个请求的Action必须满足这样的条件:当前请求URL的查询字符串和生成的HttpRouteData能够提供这种类型的所有参数。

以我们定义的DemoController为例,如果接收到的是一个URL为“/api/demo?x=1”的HTTP-GET请求,对于5个支持HTTP-GET的Action来说,只有前面3个Action方法(Get()、Retrieve()和Get(string x))的参数能够通过URL的查询字符串来提供,所以会被选择。对于其余两个Action方法(Get(string x, string y)、Get(int x, int y))来说,它们的参数y无法从请求中获得,所以会被排除在选择范围之外。

我们现在来讨论针对查询字符串和路由变量的筛选在ApiControllerActionSelector中具体是如何实现的。对于每个候选的Action,ApiControllerActionSelector都会通过一个字符串数组保存一组参数名,对应参数绑定的值来源于请求的URL。具体来说,这些参数必须满足如下三个条件:

  • 参数不应该是一个缺省参数,因为缺省参数具有默认值,对应值不一定要存在于请求的URL中。
  • 参数类型必须支持源自字符串的类型转换,因为参数值是以字符串的形式出现在URL中的。
  • 参数对应HttpParameterBinding的从当前URI中读取数据。

针对上轮筛选得到的5个Action来说,按照上述的这三个条件,这个用于保存“必须通过URL提供的参数值”的参数名称数组如左图所示。为了便于后续说明,我们将这个数组命名为UrlParameters。

在开始本轮筛选时,ApiControllerActionSelector会通过生成HttpRouteData得到所有的路由变量名,然后将表示目标HttpController名称的变量名“controller”和表示目标Action名称的变量名“action”(如果有)剔除出去,我们将得到字符串集合命名为ParameterNames1。然后它会从请求URL中提取所有的查询字符串名称,假设该字符串集合命名为ParameterNames2。最后ParameterNames1和ParameterNames2进行合并(合并时针对字符串的比较不区分大小写)得到一个新的字符串集合ParameterNames3。

本着“请求必须提供目标Action方法所需参数值”的原则,对于候选的众多Action而言,只有它们的UrlParameters是ParameterNames3的子集才会被选择。但是是否所有满足这个条件的Action都能成为 本轮筛选后剩余的成员呢?

就我们给出的例子来说,如果当前请求(HTTP-GET)的URL为“/api/demo?x=1”,那么前面3个Action满足上面的条件,是否意味着这三个Action均会来选择呢?如果请求URL变成“/api/demo?x=1&y=2”,无疑5个Action都满足上述的条件,那么本轮筛选会选择所有这5个Action吗?

就我们的经验来说,当我们调用第3个Action(Get(string x))才会采用“/api/demo?x=1”这样的URL;如果请求URL为“/api/demo?x=1&y=2”,一般访问的是最后两个Action(Get(string x, string y)、Get(int x, int y))。实际上ApiControllerActionSelector最终也是这样选择:对于众多符合条件候选Action来说,它只会保留UrlParameters元素最多哪一组Action。

上面介绍的都是请求URL具有查询字符串或者生成的HttpRouteData包含相应路由变量(不包括表示目标HttpController和Action名称的路由变量)情况下针对Action的筛选。如果URL根本不包含任何查询字符串,而且生成的HttpRouteData也不包含任何的路由变量,此时的Action筛选工作就变得简单:只会选择UrlParameters为空的Action。

综合上面两种情况下Action筛选策略,针对具有不同URL(“/api/demo”、“/api/demo?x=1”、“/api/demo?x=1&y=2”)的HTTP-GET请求,上轮筛选后剩余的5个候选Action在本轮筛选之后保留的Action列表如右图所示。

针对ActionMethodSelector进行筛选

通过前面的介绍我们知道ActionMethodSelector用于判断针对具体的请求目标Action是否是有效的,最后一轮筛选就是针对应用到Action方法上的ActionMethodSelector进行的,具体的筛选逻辑很简单:直接获取应用到候选Action方法上实现了接口IActionMethodSelector的特性,将当前HttpControllerContext和Action方法对应的MethodInfo作为参数调用其IsValidForRequest方法,只有返回值为True的Action才会被保留。

我们也知道IActionMethodSelector是一个内部接口类型,目前只有一个唯一的NoActionAttribute实现了这个接口,所以目前我们只需要关注NoActionAttribute就可以了。本轮筛选会将应用了NoActionAttribute特性的Action剔除掉。

对于我们给出的这个例子来说,只有Retrieve方法上应用了NoActionAttribute特性,所以如果它包含在候选的Action列表中,它将被剔除出去。同样是针对URL分别为“/api/demo”、“/api/demo?x=1”、“/api/demo?x=1&y=2”的三种HTTP-GET请求,最终保留下来的Action列表如图5-9所示。

异常处理

ASP.NET Web API针对请求选择Action的默认策略,即定义在ApiControllerActionSelector的SelectAction方法的实现逻辑一共会经历4轮筛选。如果最终选择的结果仅仅具有一个唯一的Action,那么它将会用于处理当前请求。此处之外,还具有如下两种异常情况:

  • 没有任何一个Action被选择
  • 具有多个匹配的Action

对于前者,ASP.NET Web API直接返回一个状态为“404, Not Found”的响应。对于后者,会因为不能决定哪个才是用于处理当前请求的Action而抛出一个InvalidOperationException异常。对于我们给出的例子来说,如果接收的HTTP-GET请求的URL分别为“/api/demo”、“/api/demo?x=1”,由于只有唯一的Action被选择,所以请求能够被正常处理。如右图所示,我们直接通过浏览器访问者两个地址,会直接得到我们希望的结果。

如果请求URL为“/api/demo?x=1&y=2”,我们知道这种情况下会有两个Action方法与请求匹配,所以这样的请求得不到正常处理。如左图所示,当我们访问这个地址的时候,浏览器直接将包含错误信息的XML呈现出来。具体的错误信息为“Multiple actions were found that match the request: System.String Get(System.String, System.String) on type WebApi.Controllers.DemoController System.String Get(Int32, Int32) on type WebApi.Controllers.DemoController”,即“在目标HttpController中定义了多个与当前请求匹配的Action”。

现在我们对DemoController作如下的修改,直接将NoActionAttribute特性应用到无参数的Retrieve方法上。

   1: public class DemoController : ApiController
   2: {
   3:     //其他成员
   4:     [HttpGet]
   5:     [ActionName("Get")]
   6:     [NoAction]
   7:     public string Retrieve()
   8:     {
   9:         return "DemoController.Retrieve()";
  10:     }
  11: }

按照上面介绍的Action选择策略,如果当前是一个URL为“/api/demo”的HTTP-GET请求,在目标HttpController中将找不到任何匹配的Action,此时客户端将接收到状态为“404,Not Found”的响应。同样通过浏览器访问这个地址,我们会得到如右图所示的结果。

ASP.NET Web API是如何根据请求选择Action的?[上篇] 
ASP.NET Web API是如何根据请求选择Action的?[下篇]

ASP.NET Web API是如何根据请求选择Action的?[下篇]的更多相关文章

  1. ASP.NET Web API是如何根据请求选择Action的?[上篇]

    ASP.NET Web API是如何根据请求选择Action的?[上篇] Web API的调用请求总是针对定义在某个HttpController中的某个Action方法,请求响应的内容来源于调用目标A ...

  2. ASP.NET Web API是如何根据请求选择Action的?[上篇] 【转】

    http://www.cnblogs.com/leo_wl/p/3316548.html ASP.NET Web API是如何根据请求选择Action的?[上篇] Web API的调用请求总是针对定义 ...

  3. ASP.NET Web API是如何根据请求选择Action的?[下篇] 【转】

    再<上篇>中我们简单介绍了用于实现Action选择机制的HttpActionSelector,接下来我们来讨论本章最为核心的内 容:ASP.NET Web API如何利用HttpActio ...

  4. Self Host模式下的ASP. NET Web API是如何进行请求的监听与处理的?

    构成ASP.NET Web API核心框架的消息处理管道既不关心请求消息来源于何处,也不需要考虑响应消息归于何方.当我们采用Web Host模式将一个ASP.NET应用作为目标Web API的宿主时, ...

  5. 【转】WCF和ASP.NET Web API在应用上的选择

    文章出处:http://www.cnblogs.com/shanyou/archive/2012/09/26/2704814.html 在最近发布的Visual Studio 2012及.NET 4. ...

  6. WCF和ASP.NET Web API在应用上的选择

    小分享:我有几张阿里云优惠券,用券购买或者升级阿里云相应产品最多可以优惠五折!领券地址:https://promotion.aliyun.com/ntms/act/ambassador/shareto ...

  7. [转载]WCF和ASP.NET Web API在应用上的选择

    http://www.cnblogs.com/shanyou/archive/2012/09/26/2704814.html http://msdn.microsoft.com/en-us/libra ...

  8. WCF和ASP.NET Web API在应用上的选择(转)

    出处:http://www.cnblogs.com/shanyou/archive/2012/09/26/2704814.html 在最近发布的Visual Studio 2012及.NET 4.5中 ...

  9. ASP.NET Web API 2.0新特性:Attribute Routing1

    ASP.NET Web API 2.0新特性:Attribute Routing[上篇] 对于一个针对ASP.NET Web API的调用请求来说,请求的URL和对应的HTTP方法的组合最终决定了目标 ...

随机推荐

  1. js手机对应的多级导航分享

    js移动导航对应,您可以使用自适应时屏幕,当小画面在一定程度上的网站.使导航出现,The navigation effects such as the following figures:多级导航! ...

  2. 虚拟WiFi

    转载用WinForm写一个虚拟WiFi助手玩玩(附源码)   这早不是什么新鲜的东西了,同类软件已经有很多,但不是收费就是有广告,在学校的时候就想自已写一个了,但那时候啥也没学,对C的掌握程度也就是定 ...

  3. vs2012 + web api + OData + EF + MYsql

    vs2012 + web api + OData + EF + MYsql 开发及部署 先说下我的情况,b/s开发这块已经很久没有搞了,什么web api .MVC.OData都只是听过,没有实际开发 ...

  4. 【OC学习-12】什么是类的继承?为什么要继承?以及继承里面的注意事项

    (1)怎样实现类的继承? //之前的继承根类,如类ASStudent继承自根类 @interface ASStudent:NSObject{ } @end //如今继承现有自己定义的类,如ASStud ...

  5. 修改vim/terminal配色

    http://blog.csdn.net/angle_birds/article/details/11694325

  6. JS代码的几个注意点规范

    也谈谈规范JS代码的几个注意点 也谈谈规范JS代码的几个注意点 写JS代码差不多也有两年了吧,从刚开始的“初生牛犊不怕虎”乱写一通到后来也慢慢知道去规范一下自己写的代码.这种感觉就像是代码是你的作品, ...

  7. TypeScript入门

    博客园首发,转载请注明出处,多谢支持.http://www.cnblogs.com/xuema/ 一.TypeScript TypeScript是一种由微软开发的自由和开源的编程语言.它是JavaSc ...

  8. Git 一些常见的命令

    git branch 查看本地所有分支 git status 查看当前状态 git commit 提交 git branch -a 查看所有的分支 git branch -r 查看远程所有分支 git ...

  9. JS时间戳比较大小:对于一组时间戳(开始时间~结束时间)和另一组时间戳进行比较,用于判断被比较时间戳组是否在要求范围内

    /* *JS时间戳比较大小:对于一组时间戳(开始时间~结束时间)和另一组时间戳进行比较,用于判断被比较时间戳组是否在要求范围内 *@param date1 date2(形如:'2015-01-01'类 ...

  10. 在VS下用C语言连接SQLServer2008

    原文:在VS下用C语言连接SQLServer2008 step1:启动SQLSERVER服务 step2:打建立数据库test,在test库中建立test表(a varchar(200),b varc ...