标签 标签 标签

  • 一句话的事儿：

说到验证，那就需要做三件事：

  • 定义验证规则
  • 按验证规则进行检查
  • 报告验证的错误。在把错误报告给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内置了对这个标准的支持，后续视频教程中可以看到。

  • 本文作者：GeekPower - Felix Sun
  • 版权声明： 本博客所有文章除特别声明外，均采用 MIT 许可协议。转载请注明出处！