Analyse du système de routage de l'API Web Asp.Net --- Méthode de déploiement WebHost

Dans l'article précédent, nous avons analysé le système de routage Asp.Net. Aujourd'hui, nous analyserons brièvement comment le système de routage de l'API Web Asp.Net est implémenté en interne lorsque l'API Web Asp.Net est déployée en mode WebHost. Commençons par un exemple simple.

Créez un projet WebApi vide et enregistrez les informations de routage dans Global :

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

Créez un projet nommé Home Controller :

  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";
    }
    
  }

Commencez à exécuter et entrez http://localhost:46351/api/home et http://localhost dans la barre d'adresse du navigateur :46351/. api/home/5, les résultats sont les suivants :

Un bref aperçu d'Asp.Net Web Exemples d'API, commençons par analyser le système de routage de l'API Web Asp.Net.

Tout d'abord, voyons comment enregistrer des routes dans l'API Web Asp.Net, comme suit :

Quelles opérations sont cachées dans cet enregistrement de route processus? ? Ci-dessous notre code source :

En regardant au code source On peut voir que l'enregistrement des routes dans l'API Web Asp.Net est en fait implémenté en appelant la méthode d'extension MapHttpRoute de type HttpRouteCollection. Dans la méthode MapHttpRoute, on voit que l'objet de routage créé est enregistré en appelant le. Ajoutez une méthode de l’objet HttpRouteCollection. Étant donné que les propriétés statiques de GlobalConfiguration sont créées par le type HostedHttpRouteCollection avec RouteTable.Routes comme paramètre de construction via Configuration et que le type HostedHttpRouteCollection est une sous-classe du type HttpRouteCollection, dans le type HostedHttpRouteCollection, la sous-classe HostedHttpRouteCollection remplace la méthode Add et CreateRoute. du type parent. La méthode est comme indiqué ci-dessous. Par conséquent, le type de l'objet de routage réellement créé est HostedHttpRoute. Cet objet de routage est enregistré dans la table de routage globale. la table de routage globale est HostedHttpRoute . Alors, à quoi sert de sauvegarder les objets de routage enregistrés dans la table de routage globale ? Ceci sera analysé dans la partie suivante ?

Comme vous pouvez le voir dans le code source ci-dessus, le dernier objet de routage créé est de type HostedHttpRoute, il y a donc maintenant un problème , nous l'avons enregistré plus tôt. Lors du routage, RouteHandler et HttpHandler ne sont pas spécifiés. Où sont-ils ajoutés à l'objet de routage ? Quels sont les secrets cachés dans le processus de création d’objets HostedHttpRoute ? Continuons à visualiser le code source :

Grâce à l'analyse ci-dessus, jusqu'à présent, nous pouvons savoir que lorsque l'API Web Asp.Net est hébergée en mode WebHost, l'objet de routage enregistré est une instance de type HostedHttpRoute, qui est enregistrée dans la table de routage globale RouteTable.Routes, et en utilisant Les RouteHandler et HttpHandler utilisés pour traiter les demandes sont respectivement des instances de type HttpControllerRouteHandler et des instances de type HttpControllerHandler.

Après avoir enregistré les informations de routage, comment utiliser les informations de routage enregistrées pour le routage dans l'API Web Asp.Net ? Sera-t-il implémenté via un HttpModule comme dans Asp.Net ? Commençons le programme et jetons un œil à l'attribut Modules dans la classe Global :

Cela se voit clairement à partir de la capture d'écran ci-dessus, on peut voir que lorsque l'API Web Asp.Net héberge des services en mode WebHost, le routage est implémenté via UrlRoutingModule, tout comme ASP.Net. D'après l'analyse précédente du système de routage Asp.Net, nous pouvons savoir qu'Asp.Net intercepte la requête via UrlRoutingModule, puis la fait correspondre séquentiellement à partir de la table de routage globale pour obtenir les RouteData qui correspondent à l'URL de la requête pour un traitement ultérieur. . Dans l'API Web Asp.Net, d'après ce qui précède, nous savons que l'objet de routage enregistré dans la table de routage globale est de type HostedHttpRoute. Continuons à analyser comment obtenir finalement le RouteData correspondant dans l'API Web Asp.Net.

Dans UrlRoutingModule, RouteData est obtenu en appelant la méthode GetRouteData de chaque objet de routage en séquence. Dans l'API Web Asp.Net, puisque le type d'objet de routage est HostedHttpRoute, regardons ce qui se passe lorsque la méthode GetRouteData est appelée :

Comme vous pouvez le voir, dans HostedHttpRoute RouteData est obtenu grâce à la méthode GetRouteData de la propriété OriginalRoute D'après l'analyse précédente, nous savons que cette propriété OriginalRoute est de type HttpWebRoute :

<.>

D'après l'analyse ci-dessus, nous pouvons voir que lorsque l'API Web Asp.Net est déployée en mode WebHost, le travail de correspondance est finalement effectué via le système de routage d'Asp.Net. Cependant, il convient de noter que la méthode de vérification des contraintes de type parent ayant été réécrite dans HttpWebRoute, l'API Web Asp.Net utilise toujours sa propre méthode pour vérifier si les contraintes correspondent :

Enfin, après avoir obtenu l'objet RouteData ainsi que les RouteHandler et HttpHandler qu'il contient grâce à une série de travaux, l'API Web Asp.Net peut les utiliser pour traiter la demande et y répondre.

Résumé :

Grâce à l'analyse ci-dessus, on peut conclure que lorsque l'API Web Asp.Net est déployée en mode WebHost, la route enregistrée est enregistrée dans le fichier global. route dans la table ; lors de l'obtention de RouteData, la correspondance de route est effectuée via les règles de correspondance du système de routage Asp.Net, mais ses propres règles de vérification de contraintes sont implémentées.

Ce qui précède représente l'intégralité du contenu de cet article. J'espère qu'il sera utile à l'apprentissage de chacun. J'espère également que tout le monde soutiendra le site Web PHP chinois.

Pour plus d'articles analysant le système de routage de l'API Web Asp.Net --- méthode de déploiement WebHost, veuillez faire attention au site Web PHP chinois !