您好,登錄后才能下訂單哦!
這篇文章主要介紹“.NET6.0中怎么自定義接口路由”,在日常操作中,相信很多人在.NET6.0中怎么自定義接口路由問題上存在疑惑,小編查閱了各式資料,整理出簡單好用的操作方法,希望對大家解答”.NET6.0中怎么自定義接口路由”的疑惑有所幫助!接下來,請跟著小編一起來學習吧!
名詞定義:端點,即我們訪問的接口或者叫API,有些地方叫EndPoint或者叫接口,其實源頭的稱呼應該叫端點會更貼切一些。或者你也可以直接叫EndPoint,但是先不管那么多,大概了解這個意思就可以了。
要了解接口路由(End Point),您需要了解什么是端點以及什么是路由。
端點是應用程序的一部分,當路由將傳入的請求映射到它時,端點就會被執行。
客戶端通常從服務器請求資源。大多數情況下,客戶端是一個瀏覽器。資源由指向特定目標的URL定義。除了網頁,它也可以是一個移動應用程序,從Web API請求特定JSON數據。
另一方面,執行的端點被映射到一個特定的路由,ASP.NET Core開發人員已經熟悉這樣一種路由模式:
app.UseRouting(); app.UseAuthorization(); app.UseEndpoints(endpoints => { endpoints.MapControllerRoute(name: "default", pattern: "{controller=Home}/{action=Index}/{id?}"); });
如果路由或路由模式與傳入請求的URL匹配,則請求將映射到該端點。ASP.NET Core
可以映射到以下端點:
Controllers (例如, MVC or web APIs)
Razor Pages
SignalR (and Blazor Server)
gRPC services
Health checks
大多數端點都有非常簡單的路由模式。只有MVC和Web API端點使用更復雜的模式。Razor頁面的路由定義基于實際頁面的文件夾和文件結構。
在ASP.NET Core 2.2中引入端點之前,路由只是運用在MVC和Web API中。Razor Pages中的隱式路由是內置的,SignalR沒有路由一說。Blazor和gRPC在當時還不不知道在哪兒,健康檢查最初是作為中間件組件實現的。
引入端點路由是為了將路由與實際端點分離,說得白話一點,就是讓URL地址和實際執行的Action進行分離,這會讓框架更加靈活,同時這意味著新的端點不需要實現自己的路由。
創建端點的最簡單方法是使用lambda:
app.Map("/map", async context => { await context.Response.WriteAsync("OK"); });
這里將/map路由映射到一個簡單的端點,該端點將單詞“OK”寫入響應流。
關于早期.NET 6.0
版本的說明
在.NET 6.0
之前,該映射只能在Startup.cs文件中的UseEndpoints方法中,而使用.NET 6.0
和新的Minimal API
方法,可以在Program.cs
文件中完成映射。
另外,我們需要將Microsoft.AspNetCore.Http命名空間添加到using語句中。
還可以將特定的HTTP方法(如GET、POST、PUT和DELETE)映射到端點。以下代碼顯示了如何映射GET和POST方法:
app.MapGet("/mapget", async context => { await context.Response.WriteAsync("Map GET"); }); app.MapPost("/mappost", async context => { await context.Response.WriteAsync("Map POST"); });
我們還可以將兩個或多個HTTP方法映射到一個端點:
app.MapMethods("/mapmethods", new[] { "DELETE", "PUT" }, async context => { await context.Response.WriteAsync("Map Methods"); });
這些端點映射很像我們在第8篇定制.NET 6.0的Middleware中間件中看到的基于lambda的中間件組件,這些管道中間件會返回結果,例如基于HTML的視圖、JSON結構化數據或類似的內容。但是,端點路由是一種更靈活的輸出方式,它應該會在ASP.NET Core 3.0以后的所有版本中進行使用。
在第8篇中,我們看到我們可以像這樣的分支管道:
app.Map("/map", mapped => { // …… });
以上這種方式也會創建一個路由,但只會偵聽以/map
開頭的URL。如果您希望有一個處理/map/{id:int?}
等模式的路由引擎,來匹配/map/456
而不是/map/abc
,那么您應該使用前面所述的新的路由。
而那些基于lambda的端點映射,對于簡單的場景非常有用。然而,由于它們是在Program.cs
中定義的,如果您想使用這種方式來實現更復雜的場景,代碼維護性將變得很差。
因此,我們應該嘗試找到一種更結構化的方法來創建自定義端點。
接下來,我們將創建一個健康檢查接口例子,有點類似于您在Kubernetes集群中運行應用程序時可能需要的接口,用來檢測系統的健康狀態:
我們從開發者的角度定義API接口,我們首先添加一個MapMyHealthChecks方法,作為IEndpointRouteBuilder對象上的一個擴展方法,它沒有實現:
app.MapMyHealthChecks("/myhealth"); app.MapControllerRoute(name: "default",pattern:"{controller=Home}/{action=Index}/{id?}");
為了避免混淆,我們這兒采取和之前類似的方式添加新接口,后面我們進一步來實現一下。
我們創建一個名為MapMyHealthChecksExtensions
的靜態類,并在MapMyHealthCheck
中放置一個擴展方法,該對象擴展IEndpointRouteBuilder
接口并返回IEndpointConventionBuilder
對象:
namespace RoutingSample; public static class MapMyHealthChecksExtensions { public static IEndpointConventionBuilder MapMyHealthChecks (this IEndpointRouteBuilder endpoints, string pattern = "/myhealth") { // ... } }
以上只是骨架,實際的接口將被實現為一個終止的中間件,也就是說,它不調用下一個的中間件組件,并創建響應流的輸出:
namespace RoutingSample; public class MyHealthChecksMiddleware { private readonly ILogger _logger; public MyHealthChecksMiddleware (RequestDelegate next, ILogger logger) { _logger = logger; } public async Task Invoke(HttpContext context) { // add some checks here... context.Response.StatusCode = 200; context.Response.ContentType = "text/plain"; await context.Response.WriteAsync("OK"); } }
實際工作是在Invoke
方法中完成的。目前,只演示200狀態碼和OK狀態響應,我們可以在這里隨意擴展該方法,例如檢查數據庫或相關服務的可用性。
接下來我們使用這個終止中間件,我們回到MapMyHealthChecks
方法的框架。我們現在創建一個自己的管道,并將其映射到給定的pipeline:
var pipeline = endpoints.CreateApplicationBuilder().UseMiddleware().Build(); return endpoints.Map(pattern, pipeline).WithDisplayName("My custom health checks");
這種方法允許我們為這個新的管道添加更多的中間件。WithDisplayName
擴展方法將配置的顯示名稱設置為接口,接下來按F5鍵啟動程序,并在瀏覽器中調用https://localhost:7111/myhealth。我們將看到:
請注意,端口號可能會有所不同。我們還可以將已經存在的終止中間件組件轉換為路由接口,以配置更加靈活的路由。
到此,關于“.NET6.0中怎么自定義接口路由”的學習就結束了,希望能夠解決大家的疑惑。理論與實踐的搭配能更好的幫助大家學習,快去試試吧!若想繼續學習更多相關知識,請繼續關注億速云網站,小編會繼續努力為大家帶來更多實用的文章!
免責聲明:本站發布的內容(圖片、視頻和文字)以原創、轉載和分享為主,文章觀點不代表本網站立場,如果涉及侵權請聯系站長郵箱:is@yisu.com進行舉報,并提供相關證據,一經查實,將立刻刪除涉嫌侵權內容。