LearnNowOnline

Blog

ASP.NET Web API: Server-Side Pipeline

Excerpt by Phil Ledgerwood | March 07, 2013

In a recent article we discussed the client-side of the Web API pipeline. This article takes a look at the server-side!

The server-side of the Web API pipeline is where most developers spend their time as this affects the Web API services, themselves. It opens up somepowerful capabilities for developers of Web API services. Virtually all the default objects in this pipeline are extensible, allowing developers to write their own custom implementations.

WCF developers will find great familiarity, here, because the Web API hooksare very similar to the hooks provided by recent versions of WCF.

Virtually every body of services has cross-cutting concerns that apply across the board and do not easily fit into single-responsibility service calls. As a result, developers often have to duplicate code or end up with service methods that are responsible for several things.

By familiarizing yourself with the server-side pipeline, you'll have the baseline concepts for adding security to all your services, adding logging, sending custom response data types, and much more.

HttpServer

The HttpServer class derives from HttpMessageHandler. It acts as the in-code representation of the server receiving the HttpRequestMessage. The HttpServer will then send the HttpRequestMessage through a configured chain of HttpMessageHandler objects.

The HttpServer object has even less properties and methods than the HttpClient object. It should truly be thought of as a bare bones sender and receiver as opposed to a container for a large degree of logic. The design of the Web API architecture encourages you to write your custom functionality in >reusable modules that can be hooked up to an HttpServer as opposed to using the actual HttpServer to get that work done.

It also bears repeating that the HttpServer itself will not have much data at all about a current request or a current response. That information is encapsulated in the HttpRequestMessage and the HttpResponseMessage objects, respectively.

HttpMessageHandler Chain

The Web API can be configured to put other classes that derive from HttpMessageHandler in the request processing chain. These handlers can read the request, manipulate it, and send a response or pass the request to the next handler in the chain. This is where most developers add custom code. This code is organized into custom message handlers that are then added to the HttpServer configuration. These handlers become organized in a chain that each request passes through. Handlers can send a response back directly or execute some code and pass the request down to the next link in the chain. This chain can be used to check every request for security keys, log data from them, etc.

The last handler in the chain is always HttpControllerDispatcher. If a handler further up the chain sends a response back to the client, the request will never 13px;">make it to the controller logic, once again making this the ideal location tocheck for authorization or any other operation you'd like to occur before the controller processes the request. The HttpResponse message is also passed up through this chain ending in the HttpServer which sends out the final response.

HttpControllerDispatcher

The HttpControllerDispatcher handler is always the last in the HttpMessageHandler chain. It takes the URL and the HTTP method from the HttpRequestMessage and routes it to the appropriate Web API controller and action.

Since this is the last HttpMessageHandler, it will not receive any requests that get completely handled and responded to by another HttpMessageHandlerfurther up the chain. This is very useful because, if you have another message handler dealing with the request, you don't want controller code to process it. If the controller sends a response, the HttpControllerDispatcher will capture the appropriate HttpResponseMessage and send it back up the handler chain.

This post is an excerpt from the online courseware for our ASP.NET Web API HTTP Pipeline course written by expert Philip Ledgerwood.