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方法中。