微軟一直以來都有提供 Model Validation 讓我們更容易的進行前置條件檢查，這次我想要在 ASP.NET Core Web API 回傳一致性的錯誤結構，捨棄預設錯誤的結構，接下來我將演練 Model Validation 以及 FluentValidation 的使用方式。
我曾經在端點使用 Dictionary<string,object> 型別，當調用端傳入 {"name":null} 時，移除 name key；傳入 {"name":"123"} 時，name 得的值等於 "123"，這樣便能夠做到類似 Json Path 的功能，參考上篇，在不改變合約的情況之下，這次我想要改用 Morcatko.AspNetCore.JsonMergePatch 來實現更新部分資源並且讓端點的合約變成強型別。
上篇 使用 PowerArgs 解析 Console / WinForm / WPF 的參數 介紹過怎麼通過 PowerArgs 解析參數、綁定行為，這次要用同事介紹的 Spectre.Console，他除了能解析參數轉成強型別之外還有很多華麗的功能，個人認為若是要設計 cli 它比 PowerArgs 來得容易些。
一直以來 Postman 都是我們調用 REST API 的首選，但經過了幾次專案的協作，總是覺得它的功能沒有那麼到位，於是我轉向別的解決方案 Jetbrains 的 Http Client 就是我這一次的標的
在軟體生命週期地演進的過程中，在不同的階段可能需要將某一些功能啟用或停用，這時候就可以選擇 Feature Toggle，微軟的 Microsoft.FeatureManagement 正好是選擇之一，除了基本的 Feature Toggle Flags 之外，也整合到 ASP.NET Core 的生命週期裡面，還有整合 Azure。下圖出自 針對目標受眾啟用分段推出功能 - Azure App Configuration | Microsoft Learn
SpecFlow + LivingDoc’s 使用起來友善度很高，測試報告的呈現也相當得清楚，甚至支援嵌入圖片、Markdown
當 SpecFlow 的測試步驟需要依賴其他物件時，SpecFlow 支援 Context Dependency Injection，只要在 Step 的建構函數開洞，SpecFlow 就會自動幫你注入
Redis 已經幾乎是系統必備的基礎建設，在本機搭建一套 Local Server，除了用於開發除錯之外，它也可以用來當成測試替身(模擬器)，接下來，就來分享我的配置
上一篇，我們學習了怎麼自訂身分驗證
ASP.NET Core 6 實作自訂 Authentication 身份驗證，以 Basic Authentication 例 | 余小章 @ 大內殿堂 - 點部落 (dotblogs.com.tw) ，如果一個服務需要有多種以上的驗證，ASP.NET Core 也有支援，接下來我們就來看看怎麼在服務裡面增加多種驗證吧
NBomber 是一個將自身定位為獨立於協議的輕量型的壓力測試套件，使用 F# 中開發的，測試可以用 F# 和 C# 編寫。它是真的開 C# 專案編寫負載測試，JMeter 和 K6 都是編譯好的二進位檔，寫測試時，需要使用他們規定的腳本語言；如果你是 C# 開發者，NBomber 就能夠很輕鬆的客製化你想要的功能
