我曾經在端點使用 Dictionary<string,object> 型別，當調用端傳入 {"name":null} 時，移除 name key；傳入 {"name":"123"} 時，name 得的值等於 "123"，這樣便能夠做到類似 Json Path 的功能，參考上篇，在不改變合約的情況之下，這次我想要改用 Morcatko.AspNetCore.JsonMergePatch 來實現更新部分資源並且讓端點的合約變成強型別。
在軟體生命週期地演進的過程中，在不同的階段可能需要將某一些功能啟用或停用，這時候就可以選擇 Feature Toggle，微軟的 Microsoft.FeatureManagement 正好是選擇之一，除了基本的 Feature Toggle Flags 之外，也整合到 ASP.NET Core 的生命週期裡面，還有整合 Azure。下圖出自 針對目標受眾啟用分段推出功能 - Azure App Configuration | Microsoft Learn
Redis 已經幾乎是系統必備的基礎建設，在本機搭建一套 Local Server，除了用於開發除錯之外，它也可以用來當成測試替身(模擬器)，接下來，就來分享我的配置
上一篇，我們學習了怎麼自訂身分驗證
ASP.NET Core 6 實作自訂 Authentication 身份驗證，以 Basic Authentication 例 | 余小章 @ 大內殿堂 - 點部落 (dotblogs.com.tw) ，如果一個服務需要有多種以上的驗證，ASP.NET Core 也有支援，接下來我們就來看看怎麼在服務裡面增加多種驗證吧
ASP.NET Core 提供了健康檢查的 Middleware，可以讓我們很輕鬆的知道應用程式目前的本身的狀態以及應用程式所依賴其他服務的狀態；也可以讓容器協調器進行重新啟動容器或是暫停服務，比如 K8s 的 Liveness、Readiness
令人驚喜的是 AspNetCore.HealthChecks.UI 提供 UI / Alert 讓監視系統變得更有效率了
以往我們在 .Net Fx 可以透過 Transforms 來切換不同的組態，而在 .NET Core 開始，則改用 Microsoft.Extensions.Configuration 來處理組態，上篇 也針對 Microsoft.Extensions.Configuration 進行了介紹，這篇將針對 .NET 應用程式注入環境的做法做一個簡單的介紹
當你的服務需要隱藏真實的訊息給調用端時，除了在每一個 Action 各自處理，Middleware 也是選擇之一，本想這應該是很簡單的操作，沒想到碰了一鼻子灰，以下是我複寫 HttpContext.Response.Body 的步驟，希望對正觀看的你有幫助。
以往，在 ASP.NET Fx / ASP.NET Core 我會先寫好 Controller(Server Code) 再搭配 NSwag、Swashbuckle.AspCore 產生 Swagger / OpenAPI Specification Doc，一旦要修改它(Spec.)就必須要重新編譯專案，只是要改文件的錯字，也沒有動到 Server Code 的邏輯，卻要重新 Build Server，幾次下來發現這樣似乎不是很聰明。也常常發生過於關注 Server Code 忽略 Specification ，導致兩邊跟不一致。
現在，我先寫 Specification，然後再透過它產生 Controller (Server Code) 讓 Specification 不再強制依賴 Server Code，解除強依賴關係，編寫規範時再也不需要重新建置專案，目前運作起來挺順暢的，接下來，我分享我是怎麼做的
驗證替使用者建立身分識別，授權則是用來判斷使用者能不能使用某一個功能，ASP.NET Core 提供許多的授權 Role、Claims、Policy 等，老實講 Policy 授權使用上有一點門檻，分享一下我的實際用法，也給需要的人參考
ASP.NET Core 提供了許多身分驗證的 Middleware，內建的 AuthenticationMiddleware (app.UseAuthentication) 需要搭配 AuthenticationHandler，這裡我將介紹如何使用自訂的身分驗證跟 AuthenticationMiddleware 的串接，驗證成功後替使用者建立身分識別