ASP.NET Web API 處理架構

這篇文章主要是介紹ASP.NET Web API的處理架構：當一個HTTP請求到達直到產生一個請求的過程。ASP.NET Web API 的處理架構圖如下，主要有三層組成：宿主（hosting），訊息處理管道（message handler pipeline）和控制器處理（controller handling）.

 

宿主（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 DeJardin在OWIN 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）

最後, 上層的控制器處理相關的流程，即:

• Action selection;
• Filter execution;
• Model binding;
• Action invocation;
• Response content creation via formatters.

這些處理過程都在 ApiController 執行個體裡頭完成, 被 HttpControllerDispatcher所調用。

上面的整個處理流程還是非常清晰地，本文只是簡單的介紹下整個處理流程，後續的文章詳細介紹各個部分。