使用ASP.NET Core 3.x 構建 RESTful API - 5.1 輸入驗證

說到驗證，那就須要作三件事： 

• 定義驗證規則 

• 按驗證規則進行檢查 

• 報告驗證的錯誤。在把錯誤報告給API消費者的時候，報告裏並不包含究竟是服務端仍是API消費者引發的錯誤，這是狀態碼的工做。而一般響應的Body裏面會包含一組驗證錯誤信息，API消費者能夠把這些信息展現給API消費者的用戶。 

 

定義驗證規則 

想要定義驗證規則，咱們可使用ASP.NET Core內置的方式或者使用第三方庫。 

在ASP.NET Core裏面，驗證規則能夠經過如下的方式來進行定義： 

• Data Annotations。例如 [Required]，[MaxLength]等等。 

• 自定義Atrribute。 

• 實現IValidatableObject接口。 

 

驗證什麼？ 

驗證的是輸入數據，而不是輸出數據。例如POST請求Body裏面的參數就須要進行驗證，而GET請求返回響應裏面的內容就不須要驗證了。 

 

按驗證規則進行檢查 

ASP.NET Core 內置了一個 ModelState對象，它用來作驗證規則檢查。 

• ModelState對象是一個Dictionary（字典），它既包含model的狀態，又包含model的綁定驗證信息。 

• 它也包含針對每一個提交的屬性值的錯誤信息的集合。每當有請求進來的時候，定義好的驗證規則就會被檢查。 

 

若是有一個規則驗證不經過的話，那麼ModelState.IsValid()方法就會返回false。並且若是傳進來的屬性的類型不正確的話，該方法也會返回false。 

 

報告驗證錯誤信息 

因爲驗證錯誤確定是由客戶端引發的，因此返回的狀態碼確定是4xx。針對驗證錯誤，具體的就是422 Unprocessable entity 這個狀態碼。 

以前也講過 422 表示服務器理解了entity的Content-Type，而且語法也正確，可是仍然沒法處理所包含的結構數據。例如：語法正確，可是語義不正確。 

 

當報告驗證錯誤信息的時候，咱們不只要使用正確的狀態碼，還須要在響應的body裏面包含驗證錯誤信息。 

REST並無規定返回的錯誤信息的格式，可是有一個標準卻規定了此事：Validation Problem Details RFC，它定義了這樣的響應的body應該是什麼樣的。ASP.NET Core內置了對這個標準的支持，後續視頻教程中能夠看到。