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来实现,这就相当于是首尾相连,但是真正实现其相连的角色而是DelegatingHandler,并且该类并非仅仅是继承,而且还进行了相应的一些扩展,下面我们来看看该类的定义:

上述重要的两个方法 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.innerHandler.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的核心之一消息处理管道做了一个稍微详细的介绍,个人觉得对消息管道原理做一个基本的了解是必须的,当需要在手动定制在各个管道时期的请求时才不至于手足无措,希望通过比较详细的介绍能够帮助到大家。

 

时间: 2024-09-25 18:05:56

Web APi之消息处理管道(五)的相关文章

ASP.NET Web API标准的“管道式”设计

  ASP.NET Web API的核心框架是一个消息处理管道,这个管道是一组HttpMessageHandler的有序组合.这是一个双工管道,请求消息从一端流入并依次经过所有HttpMessageHandler的处理.在另一端,目标HttpController被激活,Action方法被执行,响应消息随之被生成.响应消息逆向流入此管道,同样会经过逐个HttpMessageHandler的处理.这是一个独立于寄宿环境的抽象管道,如何实现对请求的监听与接收,以及将接收的请求传入消息处理管道进行处理并

Asp.Net Web API 2第十五课——Model Validation(模型验证)

原文:Asp.Net Web API 2第十五课--Model Validation(模型验证) 前言 阅读本文之前,您也可以到Asp.Net Web API 2 系列导航进行查看 http://www.cnblogs.com/aehyok/p/3446289.html 本文参考链接文章地址http://www.asp.net/web-api/overview/formats-and-model-binding/model-validation-in-aspnet-web-api 当客户端发送数

通过扩展让ASP.NET Web API支持W3C的CORS规范

让ASP.NET Web API支持JSONP和W3C的CORS规范是解决"跨域资源共享"的两种途径,在<通过扩展让ASP.NET Web API支持JSONP>中我们实现了前者,并且在<W3C的CORS Specification>一文中我们对W3C的CORS规范进行了详细介绍,现在我们通过一个具体的实例来演示如何利用ASP.NET Web API具有的扩展点来实现针对CORS的支持. 目录 一.ActionFilter OR HttpMessageHandl

ASP.NET Web API路由系统:Web Host下的URL路由

ASP.NET Web API提供了一个独立于执行环境的抽象化的HTTP请求处理管道,而ASP.NET Web API自身的路由系统也不依赖于ASP.NET路由系统,所以它可以采用不同的寄宿方式运行于不同的应用程序中.如果采用Web Host的方式将定义Web API寄宿于一个Web应用之中,其实最终的URL路由还是通过ASP.NET本身的路由系统完成的,那么两个路由系统之间是如何衔接在一起的呢?.[本文已经同步到<How ASP.NET Web API Works?>] 目录 一.Hoste

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

构成ASP.NET Web API核心框架的消息处理管道既不关心请求消息来源于何处,也不需要考虑响应消息归于何方.当我们采用Web Host模式将一个ASP.NET应用作为目标Web API的宿主时,实际上是由ASP.NET管道解决了这两个问题.具体来说,ASP.NET自身的URL路由系统借助于HttpControllerHandler这个自定义的HttpHandler实现了ASP.NET管道和ASP.NET Web API管道之间的"连通",但是在Self Host寄宿模式下,请求的

ASP.NET Web API中的Controller

虽然通过Visual Studio向导在ASP.NET Web API项目中创建的 Controller类型默认派生与抽象类型ApiController,但是ASP.NET Web API框架本身只要求它实现IHttpController接口即可,所以我们将其统称为HttpController.既然HttpController指的是所有实现了IHttpController接口的类型,我们自然得先来了解一下这个接口的定义.如下面的代码片断所示,在IHttpController接口中仅仅定义了唯一的

Web APi之认证(Authentication)两种实现方式【二】(十三)

前言 上一节我们详细讲解了认证及其基本信息,这一节我们通过两种不同方式来实现认证,并且分析如何合理的利用这两种方式,文中涉及到的基础知识,请参看上一篇文中,就不再叙述废话. 序言 对于所谓的认证说到底就是安全问题,在Web API中有多种方式来实现安全,[accepted]方式来处理基于IIS的安全(通过上节提到的WindowsIdentity依赖于HttpContext和IIS认证)或者在Web API里通过使用Web API中的消息处理机制,但是如果我们想应用程序运行在IIS之外此时Wind

ASP.NET Web API Selfhost宿主环境中管道、路由

前言 前面的几个篇幅对Web API中的路由和管道进行了简单的介绍并没有详细的去说明一些什么,然而ASP.NET Web API这个框架由于宿主环境的不同在不同的宿主环境中管道中的实现机制和路由的处理方式有着很大的不同,所以我会将对应不同的宿主环境来分别的做出简单的讲解.  ASP.NET Web API路由.管道     ASP.NET Web API 开篇介绍示例     ASP.NET Web API 路由对象介绍     ASP.NET Web API 管道模型     ASP.NET

ASP.NET Web API路由系统:路由系统的几个核心类型

虽然ASP.NET Web API框架采用与ASP.NET MVC框架类似的管道式设计,但是ASP.NET Web API管道的核心部分(定义在程序集System.Web.Http.dll中)已经移除了对System.Web.dll程序集的依赖,实现在ASP.NET Web API框架中的URL路由系统亦是如此.也就是说,ASP.NET Web API核心框架的URL路由系统与ASP.NET本身的路由系统是相对独立的.但是当我们采用基于Web Host的方式(定义在程序集System.Web.H