ASP.NET Web API 管道模型

简介:

ASP.NET Web API 管道模型

前言

ASP.NET Web API是一个独立的框架,也有着自己的一套消息处理管道,不管是在WebHost宿主环境还是在SelfHost宿主环境请求和响应都是从消息管道经过的,这是必经之地,本篇就为大家简单的介绍一下ASP.NET Web API框架中的管道对象模型。

 

 

ASP.NET Web API路由、管道

l  ASP.NET Web API 开篇介绍示例

l  ASP.NET Web API 路由对象介绍

l  ASP.NET Web API 管道模型

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

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

 

管道模型介绍

HttpMessageHandler消息处理程序(基类)

1
2
3
4
5
6
7
    publicabstractclassHttpMessageHandler : IDisposable
    {
         protectedHttpMessageHandler();
         publicvoidDispose();
         protectedvirtualvoidDispose(booldisposing);
         protectedinternalabstractTask<HttpResponseMessage>SendAsync(HttpRequestMessagerequest, CancellationTokencancellationToken);
}


上面的代码中定义的是消息处理程序基类,在管道中的每一个消息处理部分都是继承自它。

并且定义了一个会执行异步操作的SendAsync()方法,这个方法也是串联管道中各个消息处理程序的一个入口,但是并不是靠它来串联。

 

DelegatingHandler消息处理程序(基类)

1
2
3
4
5
6
7
8
9
    publicabstractclassDelegatingHandler : HttpMessageHandler
    {
         protectedDelegatingHandler();
         protectedDelegatingHandler(HttpMessageHandlerinnerHandler);
         publicHttpMessageHandlerInnerHandler {  get set ; }
  
         protectedoverridevoidDispose(booldisposing);
         protectedinternaloverrideTask<HttpResponseMessage>SendAsync(HttpRequestMessagerequest, CancellationTokencancellationToken);
}


这里的DelegatingHandler继承自HttpMessageHandler类型,而且DelegatingHandler也是抽象类型,DelegatingHandler类型并不是就是简单的继承,而是对基类进行了扩展,使之变成一个带指向箭头(对象引用)的对象类型也就是InnerHandler属性,InnerHandler属性的值就是在当前这个消息处理程序的下一个消息处理程序,DelegatingHandler类型对基类的扩展,HttpMessageHandler类型我感觉它的存在就是一个规范,从管道中的第一个处理程序开始一直到最后一个,除了最后一个消息处理程序,其他的都是DelegatingHandler类型的子类(当然也是HttpMessageHandler的子类),最后一个消息处理程序是直接继承自HttpMessageHandler类型,因为它是最后一个处理程序了不必要有指向下一个处理程序的属性,这种对职责的划分真的很优美,说不出好在哪就是觉得漂亮。

 

HttpServer消息处理程序(实现类-管道头)

1
2
3
4
5
6
7
8
9
10
11
12
13
publicclassHttpServer : DelegatingHandler
    {
         publicHttpServer();
         publicHttpServer(HttpConfigurationconfiguration);
         publicHttpServer(HttpMessageHandlerdispatcher);
         publicHttpServer(HttpConfigurationconfiguration, HttpMessageHandlerdispatcher);
         publicHttpConfigurationConfiguration {  get ; }
         publicHttpMessageHandlerDispatcher {  get ; }
  
         protectedoverridevoidDispose(booldisposing);
         protectedvirtualvoidInitialize();
         protectedoverrideTask<HttpResponseMessage>SendAsync(HttpRequestMessagerequest, CancellationTokencancellationToken);
}


HttpServer类型继承自DelegatingHandler类型,是作为管道中第一个消息处理的,要说明的是重载的这些构造函数,如果只是采用默认的构造函数的话,HttpConfiguration类型的参数默认的就是实例化HttpConfiguration类型,而HttpMEssageHandler类型的参数默认的是实例化HttpRoutingDispatcher类型的消息处理器,并且是赋值到Dispatcher属性的,是作为管道中最后一个消息处理器的(真正的操作实际不是它,后面篇幅会有讲到)。

 

HttpRoutingDispatcher消息处理程序(实现类-管道尾)

1
2
3
4
5
6
7
8
9
10
11
12
    publicclassHttpRoutingDispatcher : HttpMessageHandler
    {
         //Fields
         privatereadonlyHttpConfiguration_configuration;
         privatereadonlyHttpMessageInvoker_defaultInvoker;
  
         //Methods
         publicHttpRoutingDispatcher(HttpConfigurationconfiguration);
         publicHttpRoutingDispatcher(HttpConfigurationconfiguration, HttpMessageHandlerdefaultHandler);
         privatestaticvoidRemoveOptionalRoutingParameters(IDictionary< string object >routeValueDictionary);
         protectedoverrideTask<HttpResponseMessage>SendAsync(HttpRequestMessagerequest, CancellationTokencancellationToken);
}


HttpRoutingDispatcher类型继承自HttpMessageHandler类型,上面也说到过它是作为在管道中最后一个消息处理器的,说是可以这么说,但是真正执行的却不是它,而是在执行重载的构造函数的时候会默认的生成HttpControllerDispatcher类型作为HttpMessageHandler类型的构造函数参数,这里就不对它进行过多的阐述了,后面的篇幅自然会说明的很详细。

下面我们来看一下ASP.NET Web API管道的大概示意图。

1

wKiom1PgKSfT4RsYAAHCZPgZAb0108.jpg

(蓝色线条表示请求,红色线条表示响应)

这样的示意图说明的不是太清晰下面我们用《ASP.NET Web API 开篇介绍示例》中的SelfHost环境下的示例来演示一下,这样大家自然就会清楚这个流程了。

 

首先我们定义一个消息处理器类型命令为CustomDelegatingHandler,并且继承自DelegatingHandler类型。示例代码如下

代码1-1

1
2
3
4
5
6
7
8
9
10
11
12
13
    publicclassCustomDelegatingHandler : DelegatingHandler
    {
         protectedoverrideTask<HttpResponseMessage>SendAsync(HttpRequestMessagerequest, System.Threading.CancellationTokencancellationToken)
         {
             Console.WriteLine(request.RequestUri.OriginalString+ "____" +request.Method.Method);
  
             Task<HttpResponseMessage>responseMessage= base .SendAsync(request, cancellationToken);
  
             Console.WriteLine(responseMessage.Result.RequestMessage.Method.Method);
  
             returnresponseMessage;
         }
}


 

随之我们在SelfHost环境下的服务端在注册路由之后注册刚才我们新建的消息处理程序对象,示例代码如下:

代码1-2

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
staticvoidMain( string [] args)
         {
             HttpSelfHostConfigurationselfHostConfiguration=
                 newHttpSelfHostConfiguration( "http://localhost/selfhost" );
             using  (HttpSelfHostServerselfHostServer=newHttpSelfHostServer(selfHostConfiguration))
             {
                 selfHostServer.Configuration.Routes.MapHttpRoute(
                     "DefaultApi" "api/{controller}/{id}" new  { id=RouteParameter.Optional });
                 RegistrationMessageHandler(selfHostServer.Configuration);
  
                 selfHostServer.OpenAsync();
  
                 Console.WriteLine( "服务器端服务监听已开启" );
                 Console.Read();
             }
  
         }
         staticvoidRegistrationMessageHandler(HttpConfigurationhttpconfiguration)
         {
             httpconfiguration.MessageHandlers.Add(newHttpMessageHandlers.CustomDelegatingHandler());
         }


 

在注册完毕,并且服务器已经启动开启请求监听,客户端也随之发出请求之后,我们再来看一下客户端发出的请求以及类型,如下图。

2

wKioL1PgKmfShi5LAAOgbQwgN90619.jpg

 

这个时候我们再来看一下服务端管道处理情况,如下图。

3

wKiom1PgKVuSY0HmAAJFEVKTkr0744.jpg

每一个红框圈中的部分都表示着一个请求和响应的流程跟图2中的所有请求是对应的,可以从代码1-1中就可以看出输出的内容。

如果说这样的示例并不不明显,不能让人很清楚明白的了解管道的执行过程以及顺序,那我们定义两个处理程序,并且修改代码1-1,示例代码如下:

代码1-3

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
    publicclassCustomDelegatingHandler : DelegatingHandler
    {
         protectedoverrideTask<HttpResponseMessage>SendAsync(HttpRequestMessagerequest, System.Threading.CancellationTokencancellationToken)
         {
             Console.WriteLine( this .GetType().Name+ ":" +request.RequestUri.OriginalString+ "____" +request.Method.Method);
  
             Task<HttpResponseMessage>responseMessage= base .SendAsync(request, cancellationToken);
  
             Console.WriteLine( this .GetType().Name+ ":" +responseMessage.Result.RequestMessage.Method.Method);
  
             returnresponseMessage;
         }
    }
  
    publicclassCustomDelegatingHandler_1 : DelegatingHandler
    {
         protectedoverrideTask<HttpResponseMessage>SendAsync(HttpRequestMessagerequest, System.Threading.CancellationTokencancellationToken)
         {
             Console.WriteLine( this .GetType().Name+ ":" +request.RequestUri.OriginalString+ "____" +request.Method.Method);
  
             Task<HttpResponseMessage>responseMessage= base .SendAsync(request, cancellationToken);
  
             Console.WriteLine( this .GetType().Name+ ":" +responseMessage.Result.RequestMessage.Method.Method);
  
             returnresponseMessage;
         }
}


 

随之我们注册管理处理程序的地方也要新增一个消息处理程序,示例代码如下:

代码1-4

1
2
3
4
5
         staticvoidRegistrationMessageHandler(HttpConfigurationhttpconfiguration)
         {
             httpconfiguration.MessageHandlers.Add(newHttpMessageHandlers.CustomDelegatingHandler());
             httpconfiguration.MessageHandlers.Add(newHttpMessageHandlers.CustomDelegatingHandler_1());
         }


 

这个时候按照图2之前的那段说明操作,再看一下服务端的管道处理情况,请求还是那些个请求,看下示意图如下:

4

wKioL1PgKpSjE3ptAARBy2XFCd0591.jpg

(红框部分的代表就是跟上面所说的一样,一个请求一个响应管道所对应的处理情况)

最后再看一下图5结合图4,这样更好更容易理解。

5

wKiom1PgKYmQ05LqAAHeTWgc08Q737.jpg







     本文转自jinyuan0829 51CTO博客,原文链接:http://blog.51cto.com/jinyuan/1535778,如需转载请自行联系原作者




相关文章
|
2月前
|
JSON 监控 网络协议
干货分享“对接的 API 总是不稳定,网络分层模型” 看电商 API 故障的本质
本文从 OSI 七层网络模型出发,深入剖析电商 API 不稳定的根本原因,涵盖物理层到应用层的典型故障与解决方案,结合阿里、京东等大厂架构,详解如何构建高稳定性的电商 API 通信体系。
|
2月前
|
API
本地用阿里云API调用的r1模型,返回的think字段中有奇怪的东西,并且停止思考
这两张图片展示了模型生成内容时可能出现的异常情况,包括图像模糊、结构错误或不符合预期的结果。这可能是由于模型训练数据不足、输入指令不清晰或模型本身存在局限性所致。建议优化输入提示词或调整模型参数以提升输出质量。
|
3月前
|
缓存 自然语言处理 监控
基于通义大模型的智能客服系统构建实战:从模型微调到API部署
本文详细解析了基于通义大模型的智能客服系统构建全流程,涵盖数据准备、模型微调、性能优化及API部署等关键环节。通过实战案例与代码演示,展示了如何针对客服场景优化训练数据、高效微调大模型、解决部署中的延迟与并发问题,以及构建完整的API服务与监控体系。文章还探讨了性能优化进阶技术,如模型量化压缩和缓存策略,并提供了安全与合规实践建议。最终总结显示,微调后模型意图识别准确率提升14.3%,QPS从12.3提升至86.7,延迟降低74%。
967 14
|
8月前
|
自然语言处理 安全 API
API First:模型驱动的阿里云API保障体系
本文介绍了阿里云在API设计和管理方面的最佳实践。首先,通过API First和模型驱动的方式确保API的安全、稳定和效率。其次,分享了阿里云内部如何使用CloudSpec IDL语言及配套工具保障API质量,并实现自动化生成多语言SDK等工具。接着,描述了API从设计到上线的完整生命周期,包括规范校验、企业级能力接入、测试和发布等环节。最后,展望了未来,强调了持续提升API质量和开源CloudSpec IDL的重要性,以促进社区共建更好的API生态。
|
5月前
|
人工智能 算法 安全
OpenRouter 推出百万 token 上下文 AI 模型!Quasar Alpha:提供完全免费的 API 服务,同时支持联网搜索和多模态交互
Quasar Alpha 是 OpenRouter 推出的预发布 AI 模型,具备百万级 token 上下文处理能力,在代码生成、指令遵循和低延迟响应方面表现卓越,同时支持联网搜索和多模态交互。
411 1
OpenRouter 推出百万 token 上下文 AI 模型!Quasar Alpha:提供完全免费的 API 服务,同时支持联网搜索和多模态交互
|
6月前
|
人工智能 自然语言处理 前端开发
【2025.3.08更新】wordpress AI智能插件|自动生成SEO文章/图片/视频+长尾词优化 内置DeepSeek多模型支持与API扩展
Linkreate WordPress AI插件提供强大的自动化文章生成、SEO优化、关键词管理和内容采集功能。它能根据关键词自动生成高质量文章,支持多语言和批量生成,内置长尾关键词生成工具,并可定时自动发布文章。插件还集成了多种AI服务,支持前端AI客服窗口及媒体生成,帮助用户高效管理网站内容,提升SEO效果。
【2025.3.08更新】wordpress AI智能插件|自动生成SEO文章/图片/视频+长尾词优化 内置DeepSeek多模型支持与API扩展
|
5月前
|
人工智能 搜索推荐 IDE
突破网页数据集获取难题:Web Unlocker API 助力 AI 训练与微调数据集全方位解决方案
本文介绍了Web Unlocker API、Web-Scraper和SERP API三大工具,助力解决AI训练与微调数据集获取难题。Web Unlocker API通过智能代理和CAPTCHA绕过技术,高效解锁高防护网站数据;Web-Scraper支持动态内容加载,精准抓取复杂网页信息;SERP API专注搜索引擎结果页数据抓取,适用于SEO分析与市场研究。这些工具大幅降低数据获取成本,提供合规保障,特别适合中小企业使用。粉丝专属体验入口提供2刀额度,助您轻松上手!
272 2
|
5月前
|
人工智能 运维 安全
网络安全公司推荐:F5荣膺IDC全球Web应用与API防护领导者
网络安全公司推荐:F5荣膺IDC全球Web应用与API防护领导者
119 4
|
6月前
|
人工智能 自然语言处理 API
零门槛,即刻拥有DeepSeek-R1满血版——调用API及部署各尺寸模型
本文介绍了如何利用阿里云技术快速部署和使用DeepSeek系列模型,涵盖满血版API调用和云端部署两种方案。DeepSeek在数学、代码和自然语言处理等复杂任务中表现出色,支持私有化部署和企业级加密,确保数据安全。通过详细的步骤和代码示例,帮助开发者轻松上手,提升工作效率和模型性能。解决方案链接:[阿里云DeepSeek方案](https://www.aliyun.com/solution/tech-solution/deepseek-r1-for-platforms?utm_content=g_1000401616)。
零门槛,即刻拥有DeepSeek-R1满血版——调用API及部署各尺寸模型
|
6月前
|
XML JSON API
Understanding RESTful API and Web Services: Key Differences and Use Cases
在现代软件开发中,RESTful API和Web服务均用于实现系统间通信,但各有特点。RESTful API遵循REST原则,主要使用HTTP/HTTPS协议,数据格式多为JSON或XML,适用于无状态通信;而Web服务包括SOAP和REST,常用于基于网络的API,采用标准化方法如WSDL或OpenAPI。理解两者区别有助于选择适合应用需求的解决方案,构建高效、可扩展的应用程序。