ASP.NET Web API Processing Architecture


This post presents a first overview of the ASP.NET Web API processing architecture: what happens since a HTTP request is received until a response is produced.

Processing Architecture

The ASP.NET Web API processing architecture, represented in the following diagram, is composed by three layers: hosting, message handler pipeline and controller handling.



The lower layer is responsible for the Web API hosting, i.e., the interface between Web API and an underlying HTTP handling runtime.  Succinctly, this layer is responsible for creating HttpRequestMessage instances, and then pushing them into the upper message handler pipeline. The hosting layer is also responsible for processing the HttpResponseMessage returned back from this handler pipeline.

Currently, there are two “out-of-the-box” hosting options: self-hosting and web hosting, i.e., hosting on top of the ASP.NET classical pipeline.

Self-hosting is based on a pump that retrieves WCF Message instances from a WCF channel stack, converts them into HttpRequestMessage instances and then push those into the upper message handler pipeline.

Web-hosting is based on a specific IHttpAsyncHandler, named HttpControllerHandler, that converts HttpRequest instances into HttpRequestMessage.

The Web API hosting is not limited to these two options. There are already some additional hosts, contributed by the community:

Message Handler Pipeline

The middle layer is composed by a message handler pipeline, similar to the one that existed on WCF Web API. This pipeline is exposed by the HttpServer class, which also extends HttpMessageHandler (composite pattern).

This pipeline provides the extensibility point for “middleware” addressing cross-cutting concerns such as: logging, HTTP authentication, HTTP method translation, …

Usually, at the top of this pipeline, there is a special handler: the HttpControllerDispatcher. This handler is responsible for obtaining and calling a controller to handle the request.

The presence of this HttpControllerDispatcher is only required when using the controller-based programming model (ApiController derived classes). It is also possible to mount a completely different model, just by replacing the pipeline’s top message handler.

Controller Handling

Finally, the upper layer corresponds to the controller specific processing, namely:

This processing is done inside the ApiController instance, called by the HttpControllerDispatcher.

Final Remarks

Future posts will address each one of this layers in more details. Until then, feel free to use the comments.

7 thoughts on “ASP.NET Web API Processing Architecture

  1. Livingston

    Where can I plug into the validation? I would like to replace DataAnnotationsModelValidator and use FluentValidation on my models

      1. Livingston

        In that example, the model is validated using attributes and through the ValidationActionFilter you get access to the model state.

        what I want to do is plug into the pipeline, apply my own validation rules without attributes, which would then populate the modelsate errors accessible in ValidationActionFilter

  2. Pingback: KnowYourStack - What is ASP.NET WebAPI

  3. Pingback: Session: Deep-Dive to ASP.NET Web API - Gunnar Peipman's ASP.NET blog

  4. Pingback: ASP.Net Web API Pipeline | Stack 24/7

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s