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