The Web API Request's Journey

ASP.Net Web API Flow

ASP.NET Web API is a framework that makes it easy to build HTTP services that reach a broad range of clients, including browsers and mobile devices. ASP.NET Web API is an ideal platform for building RESTful applications on the .NET Framework. So HTTP is not just for serving up web pages. It is also a powerful platform for building APIs that expose services and data.

Hosting Web API

Web API can be hosted either on ASP.NET or you could write a Console App or a Windows Service yourself to self-host. Web API’s flexibility starts right at the core as to where it can be hosted.

·         ASP.NET Hosting: When hosted on ASP.NET, the lifecycle starts with the HttpControllerHandler which is an implementation of IHttpAsyncHandler and is responsible for passing requests into the HttpServer pipeline.

·         Self Hosting: When you are Self Hosting, the HttpServer pipeline starts at the HttpSelfHostServer which is an implementation of HttpServer and directly listens to HTTP requests.

Here is the code snippet for self-hosting Web API.

using System.Web.Http;

using System.Web.Http.SelfHost;     

var config = new HttpSelfHostConfiguration("http://localhost:8080");

config.Routes.MapHttpRoute(

    "API Default", "api/{controller}/{id}",

    new { id = RouteParameter.Optional });

using (HttpSelfHostServer server = new HttpSelfHostServer(config))

{

    server.OpenAsync().Wait();

    Console.WriteLine("Press Enter to quit.");

    Console.ReadLine();

}

HTTP Message Handlers

Once a request leaves your Service host, it travels as an HttpRequestMessage object in the pipeline. The next stage in the flow is the Message Handlers.

Delegating Handler

Delegating handlers are an extensibility point in the message flow allowing you to massage the Request before passing it on to the rest of the Web API flow. The response message on its way back has to pass through the Delegating Handler as well, so any response can also be monitored/filtered/updated at this extensibility point. Delegating Handlers if required can bypass the rest of the flow too and send back and Http Response themselves.

Routing Dispatcher
If the request makes it through the option Delegation handlers, it reaches the Routing Dispatcher next. The dispatcher checks if the Route Handler is null. If it is null, it proceeds to the next step in the flow.
However if it’s not null, it implies there are one or more per-route message handlers in place and the request is passed on to the Handlers. Here it loops through the available handlers and picks the one matching the request, the request is then handled. Remember, you can have a delegation handler in your Route Handler, so you can bypass the rest of the flow even at this point.

Controllers

The request enters the Controllers when the routing handlers pass the request to the next stage.
Authorization Filters
Authorization Filters  is the first step in the Controllers section. If there are Authorization Filters present and the request fails Authorization, the Auth filter truncates the request and sends back an Auth Failure response directly.

Model Binding
After successful authorization, the request proceeds into the Model Binding section. This is not a single step. First we look at the following three parts of HTTP Request:

·         URI Binding

The URI goes through the ModelBinderParameterBinding object which checks further if there is custom IModelBinder or IValueProvider. The final outcome is a Simple Type.

·         Formatter Binding

The Entity Body is managed through the FormatterParameterBinding. We can plug in custom Media Type Formatters and if the request needs one of these two is utilized it is piped through the appropriate Media Type Formatter before it gets converted to the required Complext Type.

·         Http Parameter Binding

If we have a custom HttpParameter binding module the entire request is piped through it instead and the final output could be any type spit out by the custom Http Parameter Binder.

Action Filters
After Model Binding is complete, the flow proceeds to the Action Filters. Action filters are actually invoked twice, before and after the controller Action.

Action Invoker
The Action Invoker invokes the Controller Action using the binding and model state in the HttpActionContext.The Action Invoker finally invokes the Controller action and the return journey of the Message in form of HttpResponseMessage begins from here. In case there is an exception while invoking the Action, the exception is routed to the Exception Filters which can send back appropriate Error Response.

Controller Action

The controller action executes the code in the Action method and returns from the Action Method. Depending on what it returns, the Result Conversion piece kicks in and prepares the HttpResponseMessage.

Result Conversion

The outcome of the Action method can be of three types

• An HttpResponseMessage – In this case, there is nothing to convert and the message is directly passed through and is on its way back in the pipeline.
• A void – If the outcome of the Action Method is a void, it is actually converted into an HttpResponseMessage with status 204 implying – No Content.
• If any other Types are returned by the Action method, Content Negotiation and Media Type Formatters kick in. The content negotiator checks to see if we can return the requested content, picks up the appropriate Media Type Formatter, churns the return data through it, to get an appropriate HttpResponseMessage out.

Once we have the required HttpResponseMessage, it begins its journey back through the components of the pipeline it traversed originally.

So that's the  Web API Request's Journey. :-)