ASP.NET Core3.X 終端中間件轉換為端點路由運作

引言

前幾天

.NET Core3.1釋出

,于是我把公司一個基礎通用系統更新了,同時删除了幾個基礎子產品當然這幾個基礎子產品與.NET Core3.1無關，其中包括了支付子產品，更新完後靜文（同僚）問我你把支付删除了啊？我說是啊，沒考慮好怎麼加上(感覺目前不太好，我需要重新設計一下)。

故事從這開始

考慮支付的時候我考慮的是将支付sdk如何直接引入到系統，以及可以有一系列支付的路由，我需要考慮的是如果建立響應給指定的位址，so我開始想如何達到我的目的自定義個中間件，Use、Run、Map???

路由的進階

路由負責将請求 URI 映射到終結點并向這些終結點排程傳入的請求。 路由在應用中定義，并在應用啟動時進行配置。 路由可以選擇從請求包含的 URL 中提取值，然後這些值便可用于處理請求。 通過使用應用中的路由資訊，路由還能生成映射到終結點的 URL。

在ASP.NET Core 2.1和更低版本中，路由是通過實作将IRouter傳入的URL映射到處理程式的接口來處理的。通常，将直接依賴MvcMiddleware添加到中間件管道末端的實作，而不是直接實作該接口。一旦請求到達MvcMiddleware，便會應用路由來确定傳入請求URL路徑所對應的控制器和操作。

然後，該請求在執行處理程式之前經過了各種MVC篩選器。這些過濾器形成了另一條“管道”，讓人聯想到中間件管道，并且在某些情況下必須複制某些中間件的行為。一個典型的例子就是CORS政策。為了對每個MVC操作以及中間件管道的其他“分支”實施不同的CORS政策，内部需要進行一定程度的重複。

“分支”中間件管道通常用于“僞路由”。如Map()在中間件管道中的擴充方法，将允許您在傳入路徑具有給定字首時有條件地執行某些中間件。

如下所示：

app.Map("/order", app => app.Run(async context =>
              {
                  await context.Response.WriteAsync("Order");
              })
            );
           

在這種情況下，該Run()方法是“終端”中間件，因為它傳回響應。但是從某種意義上說，整個Map分支對應于應用程式的“端點”.

在ASP.NET Core 2.2中，引入了終結點路由作為MVC控制器的新路由機制。此實作本質上是的内部實作MvcMiddleware .

在ASP.NET Core 2.x中使用Map()

下面我們自定義一個中間件，該中間件傳回直接傳回一個相應而不是繼續往下執行調用_next委托，一個很基本的中間件。

public class ApiEndpointMiddleware
    {
        private readonly RequestDelegate _next;

        public ApiEndpointMiddleware(RequestDelegate next)
        {
            _next = next;
        }

        public async Task InvokeAsync(HttpContext context)
        {
         
            context.Response.StatusCode = 200;

            await context.Response.WriteAsync("Order");
        }

    }           

在ASP.NET Core 2.x中，可以通過使用擴充方法指定路由通路該中間件，進而将其包含在Startup.cs的中間件管道中

public void Configure(IApplicationBuilder app)
{
    app.UseStaticFiles();

    app.Map("/order", app => app.UseMiddleware<ApiEndpointMiddleware>()); versionApp.UseMiddleware<VersionMiddleware>()); 

    app.UseMvcWithDefaultRoute();
}           

當我們通路 /order 或者 /order/1 路由都會得到自定義中間件傳回的相應。

将中間件轉換為端點路由

在ASP.NET Core 3.0中，我們使用端點路由，是以路由步驟與端點的調用是分開的。實際上，這意味着我們有兩個中間件：

• EndpointRoutingMiddleware 實際的路由，即計算将為指定的請求URL路徑調用哪個端點。
• EndpointMiddleware 所有調用的端點。

它們在中間件管道中的兩個不同點處添加，因為它們起着兩個不同的作用。一般而言，我們想的是路由中間件提前在管道中，以便後續的中間件可以通路有關将執行的端點的資訊。端點的調用應在管道的末端進行。

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

            app.UseHttpsRedirection();

            app.UseRouting();

            app.UseAuthorization();

            app.UseEndpoints(endpoints =>
            {
                endpoints.MapControllers();
            });

        }
                   

該UseRouting()擴充方法添加EndpointRoutingMiddleware到管道，同時将UseEndpoints()擴充方法添加EndpointMiddleware到管道。UseEndpoints()實際上為應用程式注冊所有端點的位置。

那麼如何将我們自定義中間件使用端點路由來映射呢？

從概念上講，我們UseEndpoints()使用/OrderURL作為比對的路徑，将“order”端點的注冊移動到調用中：

endpoints.MapControllers();
                endpoints.Map("/order",endpoints.CreateApplicationBuilder()
                .UseMiddleware<ApiEndpointMiddleware>().Build()).WithDisplayName("order-api");
           

在我們上面針對ASP.NET Core 2.x的實作中，我們将比對/order，/order/123等端點路由

例如：

endpoints.Map("/order/{action}",null);           

這将同時比對 /order /order/1，但不比對/order/status/1。它比以前的版本功能強大得多.

在上一個示例中，我們提供了一個顯示名稱（主要用于調試目的），但是我們可以附加其他的資訊，例如授權政策或CORS政策，其他中間件可以查詢這些資訊。例如：

app.UseEndpoints(endpoints =>
            {
                endpoints.MapControllers();
                endpoints.Map("/order/{action}",endpoints.CreateApplicationBuilder()
                .UseMiddleware<ApiEndpointMiddleware>().Build()).WithDisplayName("order-api").RequireCors("AllowAllHosts")
            .RequireAuthorization("AdminOnly"); 
            });
           

我們向端點添加了CORS政策（AllowAllHosts）和授權政策（AdminOnly）。當到達端點的請求到達時，并在執行端點之前采取相應的措施。

參考

https://docs.microsoft.com/en-us/aspnet/core/fundamentals/routing?view=aspnetcore-3.1#endpoint-routing-differences-from-earlier-versions-of-routing