ASP.NET Web API的核心框架是一个消息处理管道，这个管道是一组HttpMessageHandler的有序组合。这是一个双工管道，请求消息从一端流入并依次经过所有HttpMessageHandler的处理。在另一端，目标HttpController被激活，Action方法被执行，响应消息随之被生成。响应消息逆向流入此管道，同样会经过逐个HttpMessageHandler的处理。这是一个独立于寄宿环境的抽象管道，如何实现对请求的监听与接收，以及将接收的请求传入消息处理管道进行处理并将管道生成的响应通过网络回传给客户端，这就是Web API寄宿需要解决的问题。[本文已经同步到《How ASP.NET Web API Works?》]

目录
一、HttpMessageHandler
二、DelegatingHandler
三、HttpServer
四、HttpRoutingDispatcher
五、HttpControllerDispatcher

一、HttpMessageHandler

ASP.NET Web API的消息处理管道由一组HttpMessageHandler经过“首尾相连”而成，ASP.NET Web API之所以具有较高的可扩展性，主要源于采用的管道式设计。虽然ASP.NET Web API框架旨在实现针对请求的处理和响应的回复，但是采用的处理策略因具体的场景而不同。

我们不可能也没有必要创建一个“万能”的处理器来满足所有的请求处理需求，倒不如让某个处理器只负责某个单一的消息处理功能。在具体的应用场景中，我们可以根据具体的消息处理需求来选择所需的处理器并组成一个完整的消息处理管道。在这里这个用于完成某个单一消息处理功能的处理器就是 如上面的代码片断所示，抽象类HttpMessageHandler定义了一个受保护的抽象方法SendAsync，这是一个采用针对Task的“并行编程模式”的异步方法，在后续的章节中我们会看到ASP.NET Web API的应用程序接口基本上都采用这样的定义方式。对于这个SendAsync方法来说，request参数表示传递给当前HttpMessageHandler进行处理的请求，这是一个HttpRequestMessage对象。另一个参数cancellationToken是一个用于发送取消操作信号的CancellationToken对象，如果读者对.NET中的并行编程具有基本了解的话，相信对这个类型不会感到陌生。

针对请求消息和响应消息的处理均体现在这个SendAsync方法上。具体来说，针对请求消息的处理直接实现在SendAsync方法中，而针对响应消息的处理则通过其返回的Task对象来完成。由HttpMessageHandler组成的消息处理管道以及请求消息和响应消息在管道中的“流动”基本上可以通过右图来体现。

抽象类HttpMessageHandler实现了IDisposable接口，它按照“标准”的方式实现Dispose方法。如下面的代码片断所示，当我们调用Dispose方法的时候，HttpMessageHandler并没有执行任何资源回收操作。当我们通过继承这个抽象类自定义HttpMessagHandler的时候，可以将资源回收操作实现在重写的Dispose方法中。

   1: public abstract class HttpMessageHandler : IDisposable

   2: {

   3:     //其他操作

   4:     public void Dispose()

   5:     {

   6:         this.Dispose(true);

   7:         GC.SuppressFinalize(this);

   8:     }

   9:  

  10:     protected virtual void Dispose(bool disposing)

  11:     {}

  12: }

二、DelegatingHandler

我们说ASP.NET Web API消息处理管道是通过一组有序的HttpMessagHandler“首尾相连”而成，具体实现“管道串联”是通过DelegatingHandler这个类型来完成的。顾名思义，

HttpServer的Configuration和Dispatcher属性均可以在相应的构造函数中初始化。如果在构造HttpServer的时候没有显式指定这两个属性的值（调用默认的无参构造函数创建HttpServer），在默认情况下会创建一个HttpConfiguration作为Configuration的属性值，而作为Dispatcher属性值的则是一个HttpRoutingDispatcher对象，该类型定义在命名空间“System.Web.Http.Dispatcher”下。除此之外。由于

在我们引入HttpControllerDispatcher对象之后，ASP.NET Web API的消息处理管道将具有如右图所示的结构。从这个结构来看，貌似HttpControllerDispatcher才是整个消息处理管道的最后一个HttpMessageHandler。这种说法没有错，但我个人还是倾向于将HttpControllerDispatcher视为“隶属于” HttpRoutingDispatcher的“内部”HttpMessageHandler，所以仍将这个“包含” HttpControllerDispatcher的HttpRoutingDispatcher视为组成消息处理管道的最后一个HttpMessageHandler。

除此之外，“N个DelegagingHandler + 1个HttpMessageHander”这样的链式结构也刚好与基于DelegagingHandler的委托链相匹配。对于读者朋友来说，具体倾向于哪种说法并不重要，重要的是能够深刻了解整个消息处理管道的是如何构成的。