ASP.NETCoreエンドポイントルーティングの原則

エンドポイントルーティング（Endpoint Routing）は、第一級市民へASP.NET Core2.2のASP.NET Core3.0プロモーションで最初に登場しました。
ここに画像の説明を挿入

`Endpoint Routing`動機

エンドポイントルーティングが出現する前に、通常、リクエスト処理パイプラインの最後にMVCミドルウェア解決ルーティングを定義します。このアプローチは、処理パイプラインで、MVCミドルウェアの前のミドルウェアがルーティング情報を取得できないことを意味します。

ルーティング情報は、CORS、認証ミドルウェアなどの一部のミドルウェアで非常に役立ちます（ルーティング情報は認証プロセスで使用される場合があります）。

同時に、エンドポイントルーティングはエンドポイントの概念を抽出し、ルーティングマッチングロジックを分離し、配信を要求します。

`Endpoint Routing`ミドルウェア

ミドルウェアのペアで構成されます：

UseRoutingミドルウェアパイプラインにルートマッチングを追加します。ミドルウェアは、アプリケーションで定義されたエンドポイントのセットを調べ、要求に基づいて最適なものを選択します。
UseEndpointsミドルウェアパイプラインにエンドポイント実行を追加します。MapGet、およびMapPost他の方法は、処理ロジックをルーティングシステムに接続します。他の方法は、ASP.NETCoreフレームワーク機能をルーティングシステムに接続します。
MapRazorPages かみそりのページの
MapControllers コントローラ用
MapHub< THub> SignalRの場合
MapGrpcService< TService> gRPCの場合

このミドルウェアのペアの上流にあるミドルウェア：常に認識できないEndpoint;
ミドルウェアのペア間のミドルウェアは一致を認識し、Endpoint処理ロジックを追加する機能を備えています;これ
UseEndpointsはエンドポイントミドルウェアです;
一致がない場合は、入力UseEndpoints後ミドルウェア。

置かれUseRouting、UseEndpoints認証と認可のミドルウェア間：
知覚エンドポイント情報が一致し、スケジューリングEndpointアプリケーションの認可ポリシーの前に。

public void Configure(IApplicationBuilder app, IWebHostEnvironment env)
{
    
    
    if (env.IsDevelopment())
    {
    
    
        app.UseDeveloperExceptionPage();
    }

    // Matches request to an endpoint.
    app.UseRouting();

    // Endpoint aware middleware. 
    // Middleware can use metadata from the matched endpoint.
    app.UseAuthentication();
    app.UseAuthorization();

    // Execute the matched endpoint.
    app.UseEndpoints(endpoints =>
    {
    
    
        // Configure the Health Check endpoint and require an authorized user.
        endpoints.MapHealthChecks("/healthz").RequireAuthorization();

        // Configure another endpoint, no authorization requirements.
        endpoints.MapGet("/", async context =>
        {
    
    
            await context.Response.WriteAsync("Hello World!");
        });
    });
}

/healthヘルスチェックは上記で定義されています。エンドポイントはIAuthorizeDataメタデータを定義し、ヘルスチェックを実行する前に認証を必要とします。

私たちはUseRouting、UseEndpoints知覚エンドポイント：間の小さなテストコードを追加します。

   app.Use(next => context =>
    {
    
    
        var endpoint = context.GetEndpoint();
        if (endpoint is null)
        {
    
    
            return Task.CompletedTask;
        }
        Console.WriteLine($"Endpoint: {endpoint.DisplayName}");

        if (endpoint is RouteEndpoint routeEndpoint)
        {
    
    
            Console.WriteLine("Endpoint has route pattern: " +
                routeEndpoint.RoutePattern.RawText);
        }

        foreach (var metadata in endpoint.Metadata)
        {
    
    
            Console.WriteLine($"Endpoint has metadata: {metadata}");
        }
        return next(context);
    });

リクエストする/healthzと、AuthorizeAttributeメタデータを認識し
ここに画像の説明を挿入
、認証と承認のミドルウェアが機能する場合、/healthz必然的にこのAuthorizeAttributeメタデータに応答すると思います。

そこで、Github AuthorizationMiddleware 3.0のソースコードをめくります。リクエスト処理の委任が本当に注意を払っていることを発見しEndpoint、メタデータIAuthorizeData内の承認情報を抽出しました。

// ---- 截取自https://github.com/dotnet/aspnetcore/blob/master/src/Security/Authorization/Policy/src/AuthorizationMiddleware.cs-----
if (endpoint != null)
{
    
    
    context.Items[AuthorizationMiddlewareInvokedWithEndpointKey] = AuthorizationMiddlewareWithEndpointInvokedValue;
}
var authorizeData = endpoint?.Metadata.GetOrderedMetadata<IAuthorizeData>() ?? Array.Empty<IAuthorizeData>();
var policy = await AuthorizationPolicy.CombineAsync(_policyProvider, authorizeData);
if (policy == null)
{
    
    
     await _next(context);
     return;
}
var policyEvaluator = context.RequestServices.GetRequiredService<IPolicyEvaluator>();
......

テストコードが認識するのは、AuthorizeAttribute実際にIAuthorizeDataインターフェイスの実現です。

ビンゴ、ソースコードの検証を推測します。

結論として

エンドポイントルーティング：ASP.NET Coreアプリケーションが、ミドルウェアパイプラインの早い段階でスケジュールされるエンドポイントを決定できるようにします。これにより、後続のミドルウェアはこの情報を使用して、現在のパイプライン構成では提供できない機能を提供できます。

これにより、ASP.NET Coreフレームワークがより柔軟になり、エンドポイントの概念が強化され、ルーティングマッチングおよび解析機能がエンドポイントスケジューリング機能から切り離されます。