推荐学习
- 春招指南之“性能调优”:MySQL+Tomcat+JVM,还怕面试官的轰炸?
- 这是什么神仙面试宝典?半月看完25大专题,居然斩获阿里P7offer
前言
之前写过如何通过参数校验 + 统一相应码 + 统一异常处理来构建一个优雅后端接口体系:
我们做到了:
- 通过Validator + 自动抛出异常来完成了方便的参数校验
- 通过全局异常处理 + 自定义异常完成了异常操作的规范
- 通过数据统一响应完成了响应数据的规范
- 多个方面组装非常优雅的完成了后端接口的协调,让开发人员有更多的经历注重业务逻辑代码,轻松构建后端接口
这样看上去好像挺完美的,很多地方做到了统一和规范。但!事物往往是一体两面的,统一和规范带来的好处自然不必多说,那坏处呢?坏处就是不够灵活。
数据统一响应
不够灵活主要体现在哪呢,就是数据统一响应这一块。后端响应给前端的数据一共分为三个部分:
code:响应码,比如1000代表响应成功,1001代表响应失败等等
msg:响应信息,用来说明/描述响应情况
data:响应的具体数据
我们通过响应码枚举做到了code和msg的统一,无论怎样我们只会响应枚举规定好的code和msg。我天真的以为这样就能满足所有应用场景了,直到我碰到了一位网友的提问:
想请问下如果我检验的每个参数对应不同的错误信息,即code,message都不同 这样该如何处理呢?因为这些错误码是有业务含义的,比如说手机号校验的错误码是V00001,身份证号错误码是V00002。
这一下把我问的有点懵,当时回答道validation参数校验失败的话可以手动捕捉参数校验异常对象,判断是哪个字段,再根据字段手动返回错误代码。我先来演示一下我所说的这种极为麻烦的做法:
手动捕捉异常对象
因为BindingResult对象里封装了很多信息,我们可以拿到校验错误的字段名,拿到了字段名后再响应对应的错误码和错误信息。在Controller层里对BindingResult进行了处理自然就不会被我们之前写的全局异常处理给捕获到,也就不会响应那统一的错误码了,从而达到了每个字段有自己的响应码和响应信息:
@PostMapping("/addUser")public ResultVO addUser(@RequestBody @Valid User user, BindingResult bindingResult) { for (ObjectError error : bindingResult.getAllErrors()) { // 拿到校验错误的参数字段 String field = bindingResult.getFieldError().getField(); // 判断是哪个字段发生了错误,然后返回数据响应体 switch (field) { case "account"