使用ASP.NET Core 3.x 构建 RESTful API - 5.1 输入验证

说到验证,那就须要作三件事: 服务器

  • 定义验证规则 ui

  • 按验证规则进行检查 spa

  • 报告验证的错误。在把错误报告给API消费者的时候,报告里并不包含究竟是服务端仍是API消费者引发的错误,这是状态码的工做。而一般响应的Body里面会包含一组验证错误信息,API消费者能够把这些信息展现给API消费者的用户。 orm

 

定义验证规则 

想要定义验证规则,咱们可使用ASP.NET Core内置的方式或者使用第三方库。 视频

ASP.NET Core里面,验证规则能够经过如下的方式来进行定义: xml

  • Data Annotations。例如 [Required][MaxLength]等等。 对象

  • 自定义Atrribute 教程

  • 实现IValidatableObject接口。 接口

 

验证什么? 

验证的是输入数据,而不是输出数据。例如POST请求Body里面的参数就须要进行验证,而GET请求返回响应里面的内容就不须要验证了。 it

 

按验证规则进行检查 

ASP.NET Core 内置了一个 ModelState对象,它用来作验证规则检查。 

  • ModelState对象是一个Dictionary(字典),它既包含model的状态,又包含model的绑定验证信息。 

  • 它也包含针对每一个提交的属性值的错误信息的集合。每当有请求进来的时候,定义好的验证规则就会被检查。 

 

若是有一个规则验证不经过的话,那么ModelState.IsValid()方法就会返回false。并且若是传进来的属性的类型不正确的话,该方法也会返回false 

 

报告验证错误信息 

因为验证错误确定是由客户端引发的,因此返回的状态码确定是4xx。针对验证错误,具体的就是422 Unprocessable entity 这个状态码。 

以前也讲过 422 表示服务器理解了entityContent-Type,而且语法也正确,可是仍然没法处理所包含的结构数据。例如:语法正确,可是语义不正确。 

 

当报告验证错误信息的时候,咱们不只要使用正确的状态码,还须要在响应的body里面包含验证错误信息。 

REST并无规定返回的错误信息的格式,可是有一个标准却规定了此事:Validation Problem Details RFC,它定义了这样的响应的body应该是什么样的。ASP.NET Core内置了对这个标准的支持,后续视频教程中能够看到。

相关文章
相关标签/搜索