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

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

　　目录

　　一、HttpMessageHandler

　　二、DelegatingHandler

　　三、HttpServer

　　四、HttpRoutingDispatcher

　　五、HttpControllerDispatcher

　　一、HttpMessageHandler

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

　　我们不可能也没有必要创建一个“万能”的处理器来满足所有的请求处理需求，倒不如让某个处理器只负责某个单一的消息处理功能。在具体的应用场景中，我们可以根据具体的消息处理需求来选择所需的处理器并组成一个完整的消息处理管道。在这里这个用于完成某个单一消息处理功能的处理器就是HttpMessageHandler。

　　这里的“消息处理”具有两个层面的含义，既包括针对请求消息的处理，还包括针对响应消息的处理。HttpMessageHandler直接或者间接继承自具有如下定义的抽象类型HttpMessageHandler，该类型定义在命名空间“System.Net.Http”下。ASP.NET Web API通过类型HttpRequestMessage和HttpResponseMessage来表示管道处理的请求消息和响应消息，所以对HttpMessageHandler的定义就很好理解了。

　　1: public abstract class HttpMessageHandler : IDisposable

　　2: {

　　3: public void Dispose();

　　4: protected virtual void Dispose(bool disposing);

　　5: protected abstract Task SendAsync(HttpRequestMessage request, CancellationToken cancellationToken);

　　6: }

　　如上面的代码片断所示，抽象类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方法中。