wep api Life Cycle

First, let us take a look at the ASP.NET Web API life cycle for web hosting (ASP.NET) before we dive into the depths of
filters and message handlers. The application domain gets created first. Then, ASP.NET creates core objects such as
HttpContext, HttpRequest, and HttpResponse. The ASP.NET Web API application is started by creating an instance
of the WebApiApplication class, which is derived from the HttpApplication class. The Application_Start event
gets fired and the corresponding handler in Global.asax.cs is called. So far, the flow is just like any other ASP.NET
application.
The application startup maps the route template, as shown in Listing 3-1, by calling
WebApiConfig.Register(GlobalConfiguration.Configuration). MapHttpRoute, an extension method to
RouteCollection, adds a new HttpWebRoute object, with the Handler property set to HttpControllerRouteHandler
singleton, to RouteTable.Routes.

The application object goes about handling the request in the usual ASP.NET style and gets to the point where a
route handler has to be chosen. RouteTable is used to get the matching route handler (HttpControllerRouteHandler)
corresponding to the request and the GetHttpHandler() method is called off the handler, which returns a new
instance of HttpControllerHandler.
HttpControllerHandler converts the ASP.NET-specific HttpRequest into a web API abstraction of
HttpRequestMessage and dispatches it to an instance of HttpServer, which is a DelegatingHandler. Figure 3-1
illustrates the Web API life cycle and handler pipeline.

HttpServer is one of the key classes of the web API pipeline, as this is where host agnostic processing starts,
with HttpServer dealing only with the web API abstractions of the request and response, HttpRequestMessage and
HttpResponseMessage, respectively. HttpServer gets the list of delegating message handlers (common to all routes)
configured in Global.asax startup and creates Chinese boxes of handlers (or Russian matryoshka dolls, if you prefer
them to boxes) by setting the InnerHandler property of each handler in such a way that handlers are invoked in a
top-down fashion: The first handler to receive the request is the last one to be passed the response and vice versa.
HttpServer makes sure the last message handler in the all-route message handlers pipeline is HttpRoutingDispatcher.
First up is the per-route message handler pipeline. HttpRoutingDispatcher dispatches to the message handler
specified in the route. If multiple handlers (Chinese boxed through InnerHandler) are specified for the route, all message
handlers are invoked in the same fashion as all-route handlers. HttpRoutingDispatcher makes sure the last message
handler in the pipeline is HttpControllerDispatcher.

HttpControllerDispatcher dispatches to IHttpController (ApiController). The ExecuteAsync() method of
ApiController runs authorization filters, performs model binding, runs action filters, invokes the action method in
the controller, and runs exception filters. As you can see from Figure 3-1, there are two pipelines available: filters and
message handlers (DelegatingHandler). Message handlers run right after HttpServer and hence they have early
visibility in the requests. Filters run right before the action method and hence by the time a request gets to them, that
request could have been through multiple other classes. Both the pipelines are extensible and we now look at filters
and message handlers in depth.