Web API之消息处理管道
Web API之消息处理管道
前言
MVC有一套请求处理的机制,当然Web API也有自己的一套消息处理管道,该消息处理管道贯穿始终都是通过HttpMessageHandler来完成。我们知道请求信息存在 RequestMessage 中,而响应信息则存在 ResponseMessage 中,当请求信息进入到管道中,此时HttpMessageHandler会对此进行相应的处理,当执行到控制器上的方法时此时就会进行响应,生成的响应信息HttpResponseMessage就会逆向通过HttpMessageHandler依次进行处理最终返回给客户端。下面就请求管道中的对象进行详细叙述。(若有不妥之处,请海涵)。
HttpMessageHandler
此类是所有管道处理中所有对象的基类,也就是说是最重要的一个类,下面我们借助.NET Reflector打开来看看该类的定义
该类是一个抽象类并且其中最重要的两个方法是 Dispose 和 SendAsyc ,对于Dispose方法的实现,我们查看如下:

public void Dispose()
{
this.Dispose(1);
GC.SuppressFinalize(this);
return;
} protected virtual void Dispose(bool disposing)
{
}

就是个非常标准的实现资源回收的方法,但是其并未实现某个资源的回收,下面会用到,先搁置在这里。
对于第二个方法是SendAsync,看到此方法的第一个参数为HttpRequestMessage,我们能想到此方法是用来处理传递进来的请求并返回Task<HttpResponMessage>对象来响应信息,至于第二个参数是与线程有关,通知取消某个操作请参看【CancellationToken】。
DelegatingHandler
经过如上描述,对于请求和响应都是通过HttpMessageHandler来实现,这就相当于是首尾相连,但是真正实现其相连的角色而是DelegateHandler,并且该类并非仅仅是继承,而且还进行了相应的一些扩展,下面我们来看看该类的定义:
上述重要的两个方法 Dispose 和 SendAsync 以及 InnerHandler 字段,下面我们一一来看这三者。
第一个是Dispose,上述已经讲过在HttpMessageHandler中并未实现对资源的回收,从这里我们可以看出它对其进行了重写,说明可能是在其继承类DelegatingHandler中进行了资源回收,只是猜测,我们查看其具体实现就明了了。如下:

protected override void Dispose(bool disposing)
{
if (disposing == null)
{
goto Label_0029;
}
if (this.disposed != null)
{
goto Label_0029;
}
this.disposed = 1;
if (this.innerHandler == null)
{
goto Label_0029;
}
this.innerHandler.Dispose();
Label_0029:
base.Dispose(disposing);
return;
}

很显然,通过 this.Handler.Dispose(); 我们知道是实现了资源回收了的,那这个 InnerHandler 字段到底是干嘛的了,看其返回类型为HttpMessageHandler,说明是获得了HttpMessageHandler对象的引用,接着就是重写基类中的SendAsync方法,而调用此方法正是通过属性InnerHandler来调用。我们说过InnerHandler是获得对象HttpMessageHandler的引用说的更加明确就是下一个HttpMessageHandler处理程序的引用。
通过以上叙述,DelegatingHandler就是串联着整个消息处理管道,因为当前DelegatingHandler处理当前请求完成后,下一个则通过委托给HttpMessageHandler而其引用则交给InnerHandler来进行处理,则整个管道都是依托于DelegatingHandler来实现,整个过程可已将其看成是一个委托链来完成,同时命名为DelegatingHandler表面意思为委托处理这样更贴切的表达了整个过程。但是我们也应该注意到DelegatingHandler中的InnerHandler始终引用了下一个请求的处理,因为在管道中的最后一个处理程序即末尾处理程序中没有下一个处理程序,所以在最后一个处理程序中不会继承DelegatingHandler,而是继承于基类HttpMessageHandler。
对于InnerHandler的实现连接下一个HttpMessageHandler似的委托链,类似如下:

public IEnumerable<string> GetHandlerChain(DelegatingHandler handler)
{
yield return handler.GetType().Name;
while (null != handler.InnerHandler)
{
yield return handler.InnerHandler.GetType().Name;
handler = handler.InnerHandler as DelegatingHandler;
if (null == handler)
{
break;
}
}
}

HttpServer
上面我们已经讲过除了位于末尾的处理程序是基于HttpMessageHandler外,其余的都是基于DelegatingHandler。同时我们也讲过在整个管道中由InnerHandler连接着下一个HttpMessageHandler,也就是InnerHandler处于整个管道的中间,但是管道头和管道尾是哪个对象呢?管道头就是我们接下来要讲的HttpServer对象,既然该类也是处于整个管道中,则也继承于DelegatingHandler,下面我们来看看该类的定义:
通过上述知HttpServer类确确实实继承于DelegatingHandler中并且最重要的两个属性是 Configuration 和 Dispatcher ,同时这两个属性是只读的,通过查看如下知:

public HttpConfiguration Configuration
{
get
{
return this._configuration;
}
} public HttpMessageHandler Dispatcher
{
get
{
return this._dispatcher;
}
}

HttpServer类中构造函数有几个,当显式指定了上述两个属性的值则会在相应的构造函数中进行初始化,但是如果未指定两个属性的值毫无疑问则会调用默认构造函数,此时则会创建一个HttpConfiguraion作为属性Configuration的值,通过默认构造函数可得知,如下:
public HttpServer()
{
this..ctor(new HttpConfiguration());
return;
}
此时属性Dispatcher的值则是一个 HttpRoutingDispatcher 对象,(该类为管道中的尾,下面会讲)因为该属性的返回值为HttpMessageHandler而HttpRoutingDispatcher类继承于HttpMessageHandler。当HttpServer被创建后,同时此时管道中的头和尾就相继被确定了下来。从在Web API的配置文件中得知,一切配置都是基于HttpConfiguration,所以如果想在管道中自定义处理程序也就是继承于DelegatingHandler,此时进行注册该自定义处理程序当然也就得经过HttpConfiguration来实现。
HttpRoutingDispatcher
上述也对该类做了一点铺垫,此类为管道中的尾即管道中最后一个HttpMessageHandler,同时该类的对象是通过HttpSever即管道中的头的构造函数而生成。此类的定义如下:

public class HttpRoutingDispatcher : HttpMessageHandler
{
// Fields
private readonly HttpConfiguration _configuration;
private readonly HttpMessageInvoker _defaultInvoker; // Methods
public HttpRoutingDispatcher(HttpConfiguration configuration);
public HttpRoutingDispatcher(HttpConfiguration configuration, HttpMessageHandler defaultHandler);
private static void RemoveOptionalRoutingParameters(IDictionary<string, object> routeValueDictionary);
protected override Task<HttpResponseMessage> SendAsync(HttpRequestMessage request, CancellationToken cancellationToken);
}

通过上述此类的定义也验证了作为管道中的尾是继承HttpMessageHandler而非继承于DelegatingHandler,因为当Web API请求的URI是直接请求控制器上的方法,当执行完控制器上的方法时就得作出响应,而HttpRoutingDispatcher作为管道中的最后一个HttpMessageHandler,所以此时要找到控制器并激活控制器上的方法然后逆向通过管道作出响应。通过上述构造函数知,当构建HttpRoutingDispatcher对象时需要指定一个HttpConfigutaion对象,通过上述defaultHandler指定的HttpMessageHandler创建的HttpRoutingDispatcher对象就是为了激活控制器以及方法。
上述就大概介绍了Web API中整个消息管道中几个重要对象:
管道头(HttpServer)、管道中间(DelegatingHandler中的InnerHandler)、管道尾(HttpRoutingDispatcher)。
下面给出一张整个管道的大概示意图。【来源:Web API管道】
总结
本节对Web API的核心之一消息处理管道做了一个稍微详细的介绍,个人觉得对消息管道原理做一个基本的了解是必须的,当需要在手动定制在各个管道时期的请求时才不至于手足无措,希望通过比较详细的介绍能够帮助到大家。
Web API之消息处理管道的更多相关文章
- ASP.NET Web API的消息处理管道: Self Host下的消息处理管道[上篇]
ASP.NET Web API的消息处理管道: Self Host下的消息处理管道[上篇] ASP.NET Web API服务端框架核心是一个独立于具体寄宿环境的消息处理管道,它不关心请求消息来源于何 ...
- ASP.NET Web API的消息处理管道: HttpRoutingDispatcher
ASP.NET Web API的消息处理管道: HttpRoutingDispatcher 认情况下,作为消息处理管道“龙头”的HttpServer的Dispatcher属性返回一个HttpRouti ...
- ASP.NET Web API的消息处理管道:"龙头"HttpServer
ASP.NET Web API的消息处理管道:"龙头"HttpServer 一般来说,对于构成ASP.NET Web API消息处理管道的所有HttpMessageHandler来 ...
- Web APi之消息处理管道(五)
前言 MVC有一套请求处理的机制,当然Web API也有自己的一套消息处理管道,该消息处理管道贯穿始终都是通过HttpMessageHandler来完成.我们知道请求信息存在 RequestMessa ...
- ASP.NET Web API 2 消息处理管道
Ø 前言 ASP.NET 的应用程序都会有自己的消息处理管道和生命周期,比如:ASP.NET Web 应用程序(Web Form).ASP.NET MVC,还有本文将讨论的 ASP.NET Web ...
- ASP.NET Web API标准的“管道式”设计
ASP.NET Web API的核心框架是一个消息处理管道,这个管道是一组HttpMessageHandler的有序组合.这是一个双工管道,请求消息从一端流入并依次经过所有HttpMessageHan ...
- ASP.NET Web API的安全管道
本篇体验ASP.NET Web API的安全管道.这里的安全管道是指在请求和响应过程中所经历的各个组件或进程,比如有IIS,HttpModule,OWIN,WebAPI,等等.在这个管道中大致分两个阶 ...
- ASP.NET Web API标准的“管道式”设计
详见:http://www.cnblogs.com/artech/p/asp-net-web-api-pipeline.html http://www.codeproject.com/Articles ...
- ASP.NET Web API消息处理管道:Self Host下的消息处理管道[下篇]
ASP.NET Web API消息处理管道:Self Host下的消息处理管道[下篇] 我们知道ASP.NET Web API借助于HttpSelfHostServer以Self Host模式寄宿于当 ...
随机推荐
- 京东评论情感分类器(基于bag-of-words模型)
京东评论情感分类器(基于bag-of-words模型) 近期在本来在研究paraVector模型,想拿bag-of-words来做对照. 数据集是京东的评论,经过人工挑选,选出一批正面和负面的评论. ...
- uva103(最长递增序列,dag上的最长路)
题目的意思是给定k个盒子,每个盒子的维度有n dimension 问最多有多少个盒子能够依次嵌套 但是这个嵌套的规则有点特殊,两个盒子,D = (d1,d2,...dn) ,E = (e1,e2... ...
- JS获得URL参数
使用JavaScript获得URL在参数值 方法一: function getUrlParam(name) { var reg = new RegExp("(^|&)&qu ...
- AndroidUI组件之ListView小技巧
android:fadingEdge="none"//出去黑影 android:listSelector="@android:color/transparent&quo ...
- 获取LayoutInflater的三种方式
1.LayoutInflater.from(mContext); 2.Activity类的getLayoutInflater 3.(LayoutInflater)mContext.getSystemS ...
- 小强的HTML5移动开发之路(50)——jquerymobile页面初始化过程
为了方便说明和更加直观的展示jquerymobile的页面初始化过程以及各个事件的触发过程,我绘制了一幅流程图: 图中用红色框圈起来的是界面中的事件,測试代码例如以下: <!DOCTYPE ht ...
- JAVA基础编程50题(10-12题)具体解释
一.描写叙述 1.一球从m米高度自由落下.每次落地后反跳回原高度的一半:再落下,求它在 第n次落地时.共经过多少米?第10次反弹多高? 2.有1.2.3.4个数字.能组成多少个互不同样且无反复数字的三 ...
- LeanCloud获取最近会话列表和获取最后一条聊天记录
最近公司有项目需要集成IM聊天功能,领导要求用LeanCloud集成,搞不出来就要背包滚蛋啊,没办法只能硬着头皮搞了. 刚拿到官方提供的demo感觉:嗯,不错.图片语音啥的都有了,但尼玛这还不够啊,还 ...
- redirect的错误用法asp.net怎么使用自定义错误
工作了几年,写过程序也运营过网站,自定义错误也很熟悉了,最近再做项目发现有同事写了这样的代码 if (action != null) { id = Request.QueryString[" ...
- Android lint具 常见问题检查
1. Correctness 1) DuplicatedIds Layout于id应该唯一 2) NewApi 代码中使用的某些API高于Manifest中的Min SDK 3) Inconsiste ...