前回の記事では、Asp.Net ルーティング システムを分析しました。今日は、Asp.Net Web API が WebHost モードで展開されるときに、Asp.Net Web API のルーティング システムが内部でどのように実装されるかを簡単に分析します。簡単な例から始めましょう。
空の WebApi プロジェクトを作成し、グローバルにルーティング情報を登録します:
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 }); } }
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"; } }
起動して実行し、ブラウザのアドレス バーに http と入力します :// localhost:46351/api/home と http://localhost:46351/api/home/5 の結果は次のようになります:
Asp.Net Web API の例を簡単に見てみましょう。次に、Asp.Net Web API のルーティング システムの分析を開始します。
まず、次のように Asp.Net Web API にルートを登録する方法を見てみましょう:
このルート登録プロセスにはどのような操作が隠されていますか?以下はソース コードです:
ソース コードを見ると、Asp.Net Web API でのルートの登録が拡張メソッド MapHttpRoute を呼び出すことによって実際に実装されていることがわかります。 MapHttpRoute メソッドでは、HttpRouteCollection オブジェクトの Add メソッドを呼び出すことで、作成されたルート オブジェクトが保存されることがわかります。 GlobalConfiguration の静的プロパティは、Configuration を通じて RouteTable.Routes を構築パラメーターとして使用して HostedHttpRouteCollection 型によって作成され、HostedHttpRouteCollection 型は HttpRouteCollection 型のサブクラスであるため、HostedHttpRouteCollection 型では、サブクラス HostedHttpRouteCollection が Add メソッドと CreateRoute をオーバーライドします。したがって、実際に作成されるルーティング オブジェクトのタイプは、グローバル ルーティング テーブルに保存されていることがわかります。グローバル ルーティング テーブルは HostedHttpRoute です。では、登録されたルーティング オブジェクトをグローバル ルーティング テーブルに保存することは何に役立つのでしょうか? これについては、次の部分で分析します。
上記のソースコードからわかるように、最後に作成されたルートオブジェクトはHostedHttpRouteタイプなので、先ほどルートを登録したときにRouteHandlerとHttpHandlerを指定しなかったことが問題になります。ルーティングオブジェクトのどこに追加されたのでしょうか? HostedHttpRoute オブジェクトの作成プロセスに隠された秘密は何ですか?引き続きソース コードを見てみましょう:
上記の分析を通じて、これまでのところ、Asp.Net Web API が WebHost モードでホストされている場合、登録されたルーティング オブジェクトは HostedHttpRoute 型のインスタンスであり、グローバル ルーティング テーブル RouteTable.Routes に保存され、使用されることがわかります。処理用 要求された RouteHandler および HttpHandler は、それぞれ HttpControllerRouteHandler タイプおよび HttpControllerHandler タイプのインスタンスのインスタンスです。
ルーティング情報を登録した後、登録したルーティング情報を Asp.Net Web API のルーティングに使用するにはどうすればよいですか? Asp.Net のように HttpModule を通じて実装されますか? プログラムを開始して、Global クラスの Modules 属性を見てみましょう: 上のスクリーンショットから明らかなように、Asp.Net ではWeb API WebHost モードでサービスをホストする場合、ASP.Net と同様に、ルーティングは UrlRoutingModule を通じて実装されます。 Asp.Net ルーティング システムの以前の分析から、Asp.Net が UrlRoutingModule を通じて要求をインターセプトし、グローバル ルーティング テーブルから順番に照合して、後続の処理のために要求 URL に一致する RouteData を取得することがわかります。 。 Asp.Net Web API では、上記のことから、グローバル ルーティング テーブルに保存されているルーティング オブジェクトの型が HostedHttpRoute であることがわかります。Asp.Net Web API で一致する RouteData を最終的に取得する方法の分析を続けてみましょう。
UrlRoutingModuleでは、各ルーティングオブジェクトのGetRouteDataメソッドを順番に呼び出すことでRouteDataを取得します。 Asp.Net Web API では、ルーティング オブジェクトの種類は HostedHttpRoute であるため、GetRouteData メソッドが呼び出されたときに何が起こるかを見てみましょう:
ご覧のとおり、HostedHttpRoute では、RouteData は GetRouteData メソッドを通じて取得されます。はい、前の分析から、この OriginalRoute 属性は HttpWebRoute 型であることがわかります:
上記の分析からわかるように、Asp.Net Web API がWebHost モードでは、最終的には Asp.Net を通じて展開されます。ルーティング システムによってマッチング作業が完了します。ただし、親型の制約を検証するメソッドが HttpWebRoute で書き直されているため、Asp.Net Web API は引き続き独自のメソッドを使用して制約が一致するかどうかを検証することに注意してください。 RouteData オブジェクトと、それに含まれる RouteHandler および HttpHandler の一連の作業を通じて、Asp.Net Web API はこれらを使用して要求を処理し、応答することができます。
要約:
上記の分析を通じて、Asp.Net Web API が WebHost モードでデプロイされる場合、登録されたルートは RouteData を取得するときにグローバル ルーティング テーブルに保存されると結論付けることができます。 .Net Web API。.Net ルーティング システムのマッチング ルールはルーティング マッチングに使用されますが、独自の制約検証ルールを実装します。 以上がこの記事の全内容です。皆さんの学習に役立つことを願っています。また、皆さんも PHP 中国語 Web サイトをサポートしていただければ幸いです。 Asp.Net Web API ルーティング システム -- WebHost 展開方法を分析するその他の記事については、PHP 中国語 Web サイトに注目してください。