Analisi del sistema di routing dell'API Web di Asp.Net --- metodo di distribuzione di WebHost

在前一篇文章中我们分析了Asp.Net路由系统，今天我们再来简单分析一下Asp.Net Web API以WebHost方式部署时，Asp.Net Web API的路由系统内部是如何实现的。我们还是从一个简单的实例开始。

创建一个空的WebApi项目，在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 });
    }
  }

Creare un Controller chiamato 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";
    }
  }

Eseguiamo e avviamo, inseriamo rispettivamente http://localhost:46351/api/home e http://localhost:46351/api/home/5 nella barra degli indirizzi del browser, i risultati sono come segue:

　

Abbiamo dato un'occhiata rapida all'istanza di Asp.Net Web API, ora iniziamo a analizzare il sistema di rotte di Asp.Net Web API.

Prima di tutto, diamo un'occhiata al modo di registrazione delle rotte in Asp.Net Web API, come segue:

　

Quali operazioni sono nascoste nel processo di registrazione delle rotte? Di seguito esaminiamo il codice sorgente:

　

Attraverso l'esame del codice sorgente, si può vedere che la registrazione delle rotte in Asp.Net Web API viene effettivamente implementata chiamando l'estensione del metodo MapHttpRoute del tipo HttpRouteCollection. All'interno del metodo MapHttpRoute, vediamo che l'oggetto di rotta creato viene salvato chiamando il metodo Add dell'oggetto HttpRouteCollection. E poiché l'attributo statico GlobalConfiguration è di tipo HostedHttpRouteCollection creato con il costruttore RouteTable.Routes come parametro di costruzione, e poiché il tipo HostedHttpRouteCollection è un sottoclasse del tipo HttpRouteCollection, nella sottoclasse HostedHttpRouteCollection di HostedHttpRouteCollection, il metodo Add e il metodo CreateRoute del tipo superiore sono sovrascritti, come mostrato nell'immagine di seguito, quindi, in realtà, il tipo dell'oggetto di rotta creato è HostedHttpRoute. Questo oggetto di rotta viene salvato nella tabella di rotta globale, quindi possiamo sapere che il tipo dell'oggetto di rotta salvato nella tabella di rotta globale è HostedHttpRoute. Allora, a cosa serve salvare l'oggetto di rotta registrato nella tabella di rotta globale? L'analisi parte dalla parte successiva.

　

Dalla sorgente sopra, possiamo vedere che l'oggetto di rotta creato alla fine è di tipo HostedHttpRoute, quindi c'è una domanda: durante la registrazione delle rotte in precedenza, non abbiamo specificato RouteHandler e HttpHandler, da dove sono stati aggiunti all'oggetto di rotta? Durante il processo di creazione dell'oggetto HostedHttpRoute, ci sono anche segreti nascosti? Continueremo a esaminare il codice sorgente di seguito:

　

Dalla disamina sopra, fino ad ora, possiamo sapere che quando Asp.Net Web API è ospitato tramite WebHost, le istanze di rotta registrate sono di tipo HostedHttpRoute, salvate nell'elenco di rotte globale RouteTable.Routes, e i RouteHandler e HttpHandler utilizzati per elaborare le richieste sono rispettivamente di tipo HttpControllerRouteHandler e HttpControllerHandler.

　Dopo aver registrato le informazioni di rotta, come utilizza Asp.Net Web API le informazioni di rotta registrate per il routing? Sarà implementato anche come in Asp.Net tramite un HttpModule? Vediamo l'attributo Modules della classe Global:

　

Dalla schermata sopra, si può vedere chiaramente che, quando il servizio Asp.Net Web API è ospitato tramite WebHost, come in Asp.Net, il routing è implementato tramite UrlRoutingModule. Dalla disamina dell'articolo precedente sull'analisi del sistema di routing di Asp.Net, possiamo sapere che Asp.Net interrompe le richieste tramite UrlRoutingModule e poi esegue una corrispondenza sequenziale nel elenco di rotte globale per ottenere il RouteData corrispondente all'Url della richiesta per il successivo elaborazione. In Asp.Net Web API, come sappiamo dall'articolo precedente, le rotte salvate nell'elenco di rotte globale sono di tipo HostedHttpRoute, quindi continuiamo ad analizzare come Asp.Net Web API ottiene il RouteData corrispondente.

Nel RouteRoutingModule, il RouteData viene ottenuto chiamando in successione il metodo GetRouteData di ogni oggetto di rotta. In Asp.Net Web API, poiché il tipo dell'oggetto di rotta è HostedHttpRoute, diamo un'occhiata a cosa accade quando si chiama il metodo GetRouteData:

　

Si può vedere che in HostedHttpRoute viene ottenuto RouteData attraverso il metodo GetRouteData dell'attributo OriginalRoute, come abbiamo saputo dall'analisi del testo precedente, l'attributo OriginalRoute è di tipo HttpWebRoute:

　

　Dalla nostra analisi, possiamo vedere che quando Asp.Net Web API viene distribuito tramite il modo WebHost, alla fine il lavoro di corrispondenza viene completato attraverso il sistema di routing di Asp.Net. Tuttavia, è necessario notare che, poiché il metodo di convalida del tipo genitore HttpWebRoute è stato sovrascritto in HttpWebRoute, Asp.Net Web API utilizza ancora il proprio metodo per verificare se la convalida delle restrizioni corrisponde:

Infine, dopo aver ottenuto l'oggetto RouteData e il RouteHandler, HttpHandler inclusi, Asp.Net Web API può gestire le richieste e le risposte attraverso questi elementi.

　Conclusione:

Attraverso l'analisi del testo sopra, possiamo dedurre: quando Asp.Net Web API viene distribuito tramite il modo WebHost, i percorsi registrati vengono salvati nella tabella dei percorsi globali; quando si ottiene RouteData, la corrispondenza del percorso avviene attraverso le regole di corrispondenza del sistema di routing di Asp.Net, ma si realizza anche la propria regola di convalida.

Questo è tutto il contenuto dell'articolo, speriamo che sia utile per la tua apprendimento e che tu sostenga fortemente il tutorial urla.

Dichiarazione: il contenuto di questo articolo è stato tratto da Internet, il copyright è della proprietà del rispettivo autore, il contenuto è stato contribuito e caricato autonomamente dagli utenti di Internet, questo sito non detiene il diritto di proprietà, non è stato editato manualmente e non assume alcuna responsabilità legale correlata. Se trovi contenuti sospetti di violazione del copyright, ti preghiamo di inviare una e-mail a: notice#oldtoolbag.com (al momento dell'invio dell'e-mail, sostituisci # con @) per segnalare il problema e fornire prove pertinenti. Una volta verificata, questo sito eliminerà immediatamente il contenuto sospetto di violazione del copyright.