.NET 10 中的最簡 API 數據驗證:與 Tim Corey 一同深度探索
資料驗證是API開發的重要方面。 如果沒有適當的驗證,軟體應用可能會接受格式不良的數據、惡意數據或無效的請求,導致數據損壞、安全漏洞,如SQL注入、跨站腳本甚至緩衝區溢位。 確保傳入的請求格式正確,包含預期格式,並遵循後端定義的數據類型,是維護數據完整性、強大錯誤處理和開發者信任的關鍵。
在他的视频"Minimal API Data Validation Changes in .NET 10"中,Tim Corey 演示了 Minimal APIs 的 API 驗證改進,展示了開發人員如何在類和紀錄上強制全面驗證。 Tim 不僅解釋了如何防止無效數據,還演示了如何減少代碼重複,簡化驗證邏輯,以及在驗證失敗時返回正確的HTTP狀態代碼。 讓我們跟隨 Tim 的演示深入了解 Minimal APIs 的數據驗證。
Minimal API 驗證介紹
Tim Corey 首先強調指出,在 .NET 10 中,Minimal APIs 收到了多次升級,其中請求驗證是關鍵改進之一。 這允許傳入的請求無論是通過查詢字符串、頭文件還是請求正文,均可自動驗證。 Tim 強調,適當的驗證不僅改善了開發者的體驗,還防止格式不良的請求到達業務邏輯,這對於維護數據完整性和保護敏感信息至關重要。
Tim 也指出,他的视频是快速10分鐘培訓系列的一部分,旨在提供可操作的指導,而不深入抽象理論。 他鼓勵觀眾下載他的源代碼一起操作。
設置 Minimal API 用於驗證
為了展示驗證規則,Tim從文件中新建專案設置了一個Minimal API,將其簡化以專注於API驗證。 他的示例API包括:
-
測試連接的 Hello World 端點。
-
接受 Person 對象的 POST 請求 /person 端點。
- 用於 Login 紀錄的 POST 請求 /login 端點。
Tim 運行API並顯示初始接受格式不良的數據。 例如,發送空白的 Person 對象或在 Login 紀錄中無效的電子郵件仍會導致成功的API響應。 這證明需要進行結構驗證和請求驗證,以防止無效數據被後端處理。
向 Minimal API 添加驗證服務
Tim解釋說,實施適當驗證的第一步是註冊API中的驗證服務:
builder.Services.AddValidation();
通過添加此服務,路由處理器會自動對傳入的請求進行類型檢查、格式驗證和內容驗證。 Tim指出,這一步對於確保驗證失敗生成錯誤消息而不是讓惡意數據繞過系統來說是至關重要的。
類驗證範例:Person 模型
Tim 使用 System.ComponentModel.DataAnnotations 向 Person 類添加驗證屬性。 他將屬性標記為必需並強制執行帶有最小長度約束的格式驗證:
[Required]
[MinLength(2)]
public string FirstName { get; set; }
[Required]
[MinLength(2)]
public string LastName { get; set; }
現在運行API,如果請求正文缺少必需字段或包含格式不良的數據,則會觸發驗證錯誤。 例如,發送單字符 LastName 會產生 400 錯誤請求以及詳細的錯誤消息:
"欄位 LastName 必須是字符串或數組類型,最小長度為 2。"
Tim 強調使用這樣的驗證庫可減少代碼重複,讓開發者將重點放在業務邏輯上,而不是在每個路由處理器中編寫重複的驗證邏輯。
紀錄驗證範例:Login 紀錄
驗證紀錄類略有不同,因為其屬性是在構造函數中定義的。 Tim 示範如何使用 [property:] 語法在紀錄類上強制執行驗證規則:
public record Login(
[property: Required, EmailAddress] string Email,
[property: Required, MinLength(10)] string Password,
[property: Compare(nameof(Password))] string ConfirmPassword
);
Tim 解釋的關鍵要點:
-
郵件驗證確保 Email 字段遵循正確的格式。
-
密碼的最小長度保護免受格式不良的請求或弱密碼影響。
- [Compare(nameof(Password))] 確保 ConfirmPassword 與原始的 Password 匹配,避免嵌套對象中的數據損壞或驗證失敗。
Tim 進行了 login 端點的 post 請求,並展示了無效的電子郵件格式、短密碼或不匹配的確認密碼會自動觸發驗證錯誤。 一旦字段符合預期格式,API 回應就會成功。
應避免的陷阱:可訪性的重要性
Tim 指出一個細微的陷阱:如果類或紀錄不是公開的,驗證會靜默失敗。 即使API請求成功綁定到對象,驗證結果也不會被強制執行:
internal record Login(...); // 驗證不會運行
他解釋說,雖然惡意數據或無效輸入可能仍會填充對象,但驗證策略則被繞過。 這種行為在 ASP.NET Core 中有文檔說明,但 Visual Studio 不會警告開發者,因此定期檢查驗證規則並確保所有API模型都是公開的非常重要。
使用 Minimal API 驗證的優勢
Tim 採納了總結,概述了 Minimal API 中 API 數據驗證的優點:
-
消除了手動驗證邏輯:不需為每個屬性編寫重複檢查。
-
確保數據完整性:防止格式不良的請求破壞後端或嵌套對象。
-
提升安全性:減少暴露於惡意數據、SQL 注入、跨站腳本及其他安全漏洞。
-
提供明確的錯誤消息:返回帶有錯誤消息和正確的 HTTP 狀態代碼(如 400 錯誤請求)的驗證失敗。
-
提升開發者體驗:乾淨的宣告式驗證減少了代碼重複並提高了對API回應的信任。
- 支持全面驗證:自動用於請求正文、查詢字符串、頭文件及嵌套對象。
通過Tim的方法,開發者可以實作全面驗證,而無需撰寫自定義驗證器方法或在多個端點中重複驗證邏輯。
結論
Tim Corey 的視頻提供了在 Minimal APIs 中使用 .NET 10 實作API驗證的實用步驟指南。 從添加驗證服務到用屬性裝飾類和紀錄,再到理解潛在陷阱,Tim展示了如何有效地強制執行資料完整性、格式驗證和錯誤處理。
適當的API資料驗證可確保您的REST API僅處理格式良好的請求,從而降低來自惡意資料、SQL注入、跨站腳本以及其他安全漏洞的風險。 使用驗證規則、結構驗證和適當的驗證策略,可以加強開發者的信任,同時保持綺麗而安全的後端。
通過遵循Tim的指導,開發者能夠實作一個堅固、安全並可靠的驗證管道,確保每次發帖請求、每個對象、每個API請求都符合預期格式,從而保護後端和最終用戶。
