Analysis of the Routing System of Asp.Net Web API---WebHost Deployment Methods

In the previous article, we analyzed the Asp.Net routing system. Today, let's briefly analyze how the routing system of Asp.Net Web API is implemented internally when deployed as a WebHost. We will start with a simple example.

Create an empty WebApi project, register route information in Global:

  public class WebApiApplication : System.Web.HttpApplication
  {
    protected void Application_Start()
    {
      //Register route
      GlobalConfiguration.Configuration.Routes.MapHttpRoute(
        name: "default",
        routeTemplate: "api"/{controller}/{id}", 
        defaults: new { id = RouteParameter.Optional });
    }
  }

Create a Controller named Home:

  public class HomeController : ApiController
  {
    // GET: api/Home
    public IEnumerable<string> Get()
    {
      return new string[] { "value1", "value2" };
    }
    // GET: api/Home/5
    public string Get(int id)
    {
      return "value";
    }
  }

Start running, enter http: in the address bar of the browser separately//localhost:46351/api/home and http://localhost:46351/api/home/5, the result is as follows:

　

A brief look at an instance of Asp.Net Web API, and then we will start to analyze the routing system of Asp.Net Web API.

First, let's take a look at the way of route registration in Asp.Net Web API, as follows:

　

What operations are hidden in this route registration process? Below is our source code:

　

By examining the source code, we can see that the registration of routes in Asp.Net Web API is actually achieved by calling the extension method MapHttpRoute of the HttpRouteCollection type. Inside the MapHttpRoute method, we see that the route object created is saved by calling the Add method of the HttpRouteCollection object. Since the static property of GlobalConfiguration is of type HostedHttpRouteCollection, which is created with RouteTable.Routes as the constructor parameter, and because HostedHttpRouteCollection is a subclass of HttpRouteCollection, in the HostedHttpRouteCollection type, the subclass HostedHttpRouteCollection overrides the Add method and CreateRoute method of the parent type, as shown in the figure below. Therefore, the actual type of the route object created is HostedHttpRoute. This route object is saved in the global route table, from which we can know that the type of the route object saved in the global route table is HostedHttpRoute. Then, what is the use of saving the registered route object in the global route table? The subsequent part will be analyzed.

　

From the above source code, we can see that the last created route object is of the HostedHttpRoute type. Now there is a question, when we registered the route before, we did not specify the RouteHandler and HttpHandler, where did they come from and get added to the route object? What hidden secrets are there in the process of creating the HostedHttpRoute object? We will continue to view the source code below:

　

Through the analysis in the above text, so far, we can know that when Asp.Net Web API is hosted in the WebHost mode, the registered route object is an instance of the HostedHttpRoute type, stored in the global route table RouteTable.Routes, and the RouteHandler and HttpHandler used to process requests are instances of the HttpControllerRouteHandler type and HttpControllerHandler type, respectively.

　After registering the route information, how does Asp.Net Web API use the registered route information for routing? Will it also be implemented through an HttpModule like in Asp.Net? Let's start the program and take a look at the Modules property in the Global class:

　

From the above screenshot, it can be clearly seen that when the Asp.Net Web API is hosted in the WebHost mode, it is also like ASP.Net, routing is implemented through the UrlRoutingModule. From the analysis of the Asp.Net routing system in the previous article, we can know that Asp.Net intercepts the request through the UrlRoutingModule and then matches it sequentially from the global route table to obtain the RouteData that matches the request URL for subsequent processing. In Asp.Net Web API, from the above text, we know that the route object stored in the global route table is of the HostedHttpRoute type, and we continue to analyze how the matching RouteData is obtained in Asp.Net Web API.

In the UrlRoutingModule, RouteData is obtained by sequentially calling the GetRouteData method of each route object. In Asp.Net Web API, since the type of the route object is HostedHttpRoute, let's take a look at what happens when the GetRouteData method is called:

　

It can be seen that in HostedHttpRoute, the RouteData is obtained through the GetRouteData method of the OriginalRoute attribute, and from the previous analysis, we know that this OriginalRoute attribute is of the HttpWebRoute type:

　

　From the above analysis, we can see that when Asp.Net Web API is deployed in the WebHost mode, it ultimately completes the matching work through the Asp.Net routing system. However, it is necessary to note that due to the rewriting of the validation constraint method of the parent type in HttpWebRoute, Asp.Net Web API still uses its own way to validate whether the constraint matches:

Finally, after obtaining the RouteData object and the RouteHandler, HttpHandler contained in it through a series of operations, Asp.Net Web API can handle requests and responses through these obtained ones.

　Summary:

Through the analysis in the above text, we can conclude that: when deploying Asp.Net Web API in the WebHost mode, the registered routes are stored in the global route table; when obtaining RouteData, it is matched through the matching rules of the Asp.Net routing system, but it has implemented its own constraint validation rules.

That's all for the content of this article. I hope it will be helpful to everyone's learning, and I also hope everyone will support the Yell Tutorial more.

Declaration: The content of this article is from the network, and the copyright belongs to the original author. The content is contributed and uploaded by Internet users spontaneously. This website does not own the copyright, has not been manually edited, and does not assume relevant legal liabilities. If you find any suspected copyright content, please send an email to: notice#w3Please report any infringement by sending an email to codebox.com (replace # with @ when sending email), and provide relevant evidence. Once verified, this site will immediately delete the suspected infringing content.