ASP.NET Web API 处理架构

这篇文章主要是介绍ASP.NET Web API的处理架构:当一个HTTP请求到达直到产生一个请求的过程。ASP.NET Web API 的处理架构图如下,主要有三层组成:宿主(hosting),消息处理管道(message handler pipeline)和控制器处理(controller handling).

processing-architecture 

宿主(Hosting)

底层负责Web API的宿主,Web API之间的接口和HTTP 处理引擎。一句话,这一层负责创建HttpRequestMessage实例。然后把他们推入到上层的消息处理管道。宿主层也负责消息处理管道返回的HttpResponseMessage 。目前在ASP.NET Web API里头已经内建的宿主选项有2个:self-hosting 和 web hosting, web hosting也就是宿主在IIS的ASP.net 的处理管道里,Self-hosting 是基于WCF channel stack,的 WCF Message 实例  ,然后转换到 HttpRequestMessage 实例然后把他们推给上层的消息处理管道。 Web-hosting 是基于IHttpAsyncHandler, 命名为 HttpControllerHandler, 它把 HttpRequest 转换为HttpRequestMessage.当然Web API hosting 是可扩展的,不仅仅局限于这两个选项,你可以根据自己的需求定制,社区已经有人实现第三方的宿主Louis DeJardinOWIN created a host 。 

消息处理管道(Message Handler Pipeline)

中间层是 message handler pipeline,这一部分就是 WCF Web API 的内容了,通过 HttpServer 类暴露, 他也扩展了 HttpMessageHandler 。这条管道提供了中间层的各种扩展点(addressing cross-cutting concerns)例如: 日志, HTTP 验证, ……

通常在这个管道的顶端是一个特殊的处理器: HttpControllerDispatcher。这个处理器负责获取和调用 一个  控制器(Controler) 处理请求。只是在使用基于控制器的编程模型(ApiController的派生类)的时候才使用HttpControllerDispatcher ,也可以使用完全不同的模型,只需要把最顶端的这个消息处理器替换掉就可以哦。

控制器处理(Controller Handling)

最后, 上层的控制器处理相关的流程,即:

这些处理过程都在 ApiController 实例里头完成, 被 HttpControllerDispatcher所调用。

上面的整个处理流程还是非常清晰地,本文只是简单的介绍下整个处理流程,后续的文章详细介绍各个部分。

我觉得大部分人都是“眼球动物“,他们关注的往往都是目光所及的东西。对于很多软件从业者来说,他们对看得见(具有UI界面)的应用抱有极大的热忱,但是对背后支撑整个应用的服务却显得较为冷漠。如果我们将整个“生态系统”比喻成海面上漂浮的冰山,我们所能看的到的只是露出水面的冰山一角,水面之下才是一个“庞然大物”。 提到服务,我们自然想到Web Service。但是传统意义上的Web Service却有点名不副实,因为支撑它的其实不是Web而是SOAP,承载一个Web Service甚至可以根本不需要Web。随着互联网的普及,互联网应用(尤其移动互联网应用)已经成为主流,“SOAP之重”已经越来越令我们无法承受,于是采用REST架构风格并直接采用Web进行通信的轻量级Web Service走进了我们的视野并登堂入室。为了与传统的基于SOAP的Web Service以示区别,我们将后者称为Web API。 很多人鼓吹SOAP已死,我个人对此持不同的看法。上面讲的“重”与“轻”都是不带任何感情色彩的中性词,至于优劣评价则决定于它们是否适合应用的场景。到目前为止,对于企业级应用之间的内部集成互联,我觉得传统的Web Service依然是最好的选择。传统Web Service应用的领域貌似在不断被Web API占据,但是后者并不能完全被视为前者的替代品,它只是让“踩过界”的Web Service退回到它应该坚守的领地。Web Service和Web API在各自适合的领域各司其职,使“路归路、桥归桥”是一种理想的状态。 Web Service和Web API的合理布局同样也体现在微软技术平台上。WCF在过去是唯一的选择,这是一个具有“SOAP”基因的通信平台,微软后来利用扩展让它提供了针对REST的支持。正因为如此,如果使用WCF来构建Web API的话,我们依然需要采用传统的编程方式,Web API的“简单、快捷”完全得不到体现。微软意识到在一个“重量级”通信框架上通过扩展实现“轻量级”的通信,还不如重新构建一个通信平台,于是ASP.NET Web API应运而生。
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值