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








本文转自Jeffcky博客园博客,原文链接:http://www.cnblogs.com/CreateMyself/p/4832643.html,如需转载请自行联系原作者
目录
相关文章
|
2月前
|
Java API 数据库
构建RESTful API已经成为现代Web开发的标准做法之一。Spring Boot框架因其简洁的配置、快速的启动特性及丰富的功能集而备受开发者青睐。
【10月更文挑战第11天】本文介绍如何使用Spring Boot构建在线图书管理系统的RESTful API。通过创建Spring Boot项目,定义`Book`实体类、`BookRepository`接口和`BookService`服务类,最后实现`BookController`控制器来处理HTTP请求,展示了从基础环境搭建到API测试的完整过程。
52 4
|
2月前
|
XML JSON API
ServiceStack:不仅仅是一个高性能Web API和微服务框架,更是一站式解决方案——深入解析其多协议支持及简便开发流程,带您体验前所未有的.NET开发效率革命
【10月更文挑战第9天】ServiceStack 是一个高性能的 Web API 和微服务框架,支持 JSON、XML、CSV 等多种数据格式。它简化了 .NET 应用的开发流程,提供了直观的 RESTful 服务构建方式。ServiceStack 支持高并发请求和复杂业务逻辑,安装简单,通过 NuGet 包管理器即可快速集成。示例代码展示了如何创建一个返回当前日期的简单服务,包括定义请求和响应 DTO、实现服务逻辑、配置路由和宿主。ServiceStack 还支持 WebSocket、SignalR 等实时通信协议,具备自动验证、自动过滤器等丰富功能,适合快速搭建高性能、可扩展的服务端应用。
143 3
|
1月前
|
前端开发 API 开发者
Python Web开发者必看!AJAX、Fetch API实战技巧,让前后端交互如丝般顺滑!
在Web开发中,前后端的高效交互是提升用户体验的关键。本文通过一个基于Flask框架的博客系统实战案例,详细介绍了如何使用AJAX和Fetch API实现不刷新页面查看评论的功能。从后端路由设置到前端请求处理,全面展示了这两种技术的应用技巧,帮助Python Web开发者提升项目质量和开发效率。
44 1
|
1月前
|
JSON API 数据格式
如何使用Python和Flask构建一个简单的RESTful API。Flask是一个轻量级的Web框架
本文介绍了如何使用Python和Flask构建一个简单的RESTful API。Flask是一个轻量级的Web框架,适合小型项目和微服务。文章从环境准备、创建基本Flask应用、定义资源和路由、请求和响应处理、错误处理等方面进行了详细说明,并提供了示例代码。通过这些步骤,读者可以快速上手构建自己的RESTful API。
38 2
|
2月前
|
监控 负载均衡 API
Web、RESTful API 在微服务中有哪些作用?
在微服务架构中,Web 和 RESTful API 扮演着至关重要的角色。它们帮助实现服务之间的通信、数据交换和系统的可扩展性。
51 2
|
2月前
|
人工智能 搜索推荐 API
用于企业AI搜索的Bocha Web Search API,给LLM提供联网搜索能力和长文本上下文
博查Web Search API是由博查提供的企业级互联网网页搜索API接口,允许开发者通过编程访问博查搜索引擎的搜索结果和相关信息,实现在应用程序或网站中集成搜索功能。该API支持近亿级网页内容搜索,适用于各类AI应用、RAG应用和AI Agent智能体的开发,解决数据安全、价格高昂和内容合规等问题。通过注册博查开发者账户、获取API KEY并调用API,开发者可以轻松集成搜索功能。
|
2月前
|
前端开发 JavaScript API
惊呆了!学会AJAX与Fetch API,你的Python Web项目瞬间高大上!
在Web开发领域,AJAX与Fetch API是提升交互体验的关键技术。AJAX(Asynchronous JavaScript and XML)作为异步通信的先驱,通过XMLHttpRequest对象实现了局部页面更新,提升了应用流畅度。Fetch API则以更现代、简洁的方式处理HTTP请求,基于Promises提供了丰富的功能。当与Python Web框架(如Django、Flask)结合时,这两者能显著增强应用的响应速度和用户体验,使项目更加高效、高大上。
51 2
|
2月前
|
前端开发 API 开发者
从零到精通,AJAX与Fetch API让你的Python Web前后端交互无所不能!
从零到精通,AJAX与Fetch API让你的Python Web前后端交互无所不能!
45 3
|
2月前
|
移动开发 前端开发 JavaScript
前端开发实战:利用Web Speech API之speechSynthesis实现文字转语音功能
前端开发实战:利用Web Speech API之speechSynthesis实现文字转语音功能
208 0
|
3月前
|
存储 JSON API
实战派教程!Python Web开发中RESTful API的设计哲学与实现技巧,一网打尽!
在数字化时代,Web API成为连接前后端及构建复杂应用的关键。RESTful API因简洁直观而广受欢迎。本文通过实战案例,介绍Python Web开发中的RESTful API设计哲学与技巧,包括使用Flask框架构建一个图书管理系统的API,涵盖资源定义、请求响应设计及实现示例。通过准确使用HTTP状态码、版本控制、错误处理及文档化等技巧,帮助你深入理解RESTful API的设计与实现。希望本文能助力你的API设计之旅。
68 3