1. 什么时候我们会前、后端校验?
正常情况下,前后端对于请求的参数都需要校验的,这能提高应用程序的稳定性、可维护性,而对于前后台如果能将这种不可缺少校验规则汇总并制定一套规范,在每一个应用程序中都使用这种规范,能给带来不少好处。那在哪些情况下适合使用前、后端校验了:
2. 前端请求参数校验
常用的方式有这些:
3. 后端请求参数校验
常用的方式有这些:
@RequestParam(value = "mobile", required = true) String mobile
虽然到这里通过hibernate-validator来做分组校验就可以解决所有方式的参数校验:
但也存在问题,后端校验的确做到了,但如果要将这些参数校验都编写到接口文档中,这个时候我们还需要先找接口、找到分组、找到dto下分组对应的所有参数校验,增加参数校验规则还得重新修改接口文档等等。
4. 后端参数校验总结
目前后端校验基本就是上面我提到的几种常用方式,但这些方式都有缺点,基本上hibernate-validator已经算是比较好的了,所以这里推荐使用(适用于大部分项目),使用hibernate-validator也存在问题,就是接口文档编写,这里引入一个接口管理框架swagger,swagger可以统一管理api并将api提供给前端人员,swagger目前可以做到通过编写yaml文件,根据yaml中的参数必填的属性配置,可以通过yaml生成对应的接口代码且接口代码中已经做了参数校验,以后对于参数校验可以直接修改yaml文件并重新生成就行了,同时yaml还可以直接提供给前端人员做mock或生成接口文档。对于yaml生成后端代码,我会在后面的博客继续提到,这里只简单提到对于hibernate-validator文档管理痛点引入的swagger yaml生成后端代码。
基于yaml生成的后端代码:
public ResponseEntity<ApiCommonResultVo> loginUsingPOST(@NotNull @ApiParam(value = "账号", required = true) @Valid @RequestParam(value = "mobile", required = true) String mobile,@NotNull @ApiParam(value = "密码", required = true) @Valid @RequestParam(value = "password", required = true) String password) {
String accept = request.getHeader("Accept");
if (accept != null && accept.contains("")) {
try {
return new ResponseEntity<ApiCommonResultVo>(objectMapper.readValue("", ApiCommonResultVo.class), HttpStatus.NOT_IMPLEMENTED);
} catch (IOException e) {
log.error("Couldn't serialize response for content type ", e);
return new ResponseEntity<ApiCommonResultVo>(HttpStatus.INTERNAL_SERVER_ERROR);
}
}
log.info("login success...");
return new ResponseEntity<ApiCommonResultVo>(HttpStatus.NOT_IMPLEMENTED);
}
(adsbygoogle = window.adsbygoogle || []).push({});