【项目实践】后端接口统一规范的同时,如何优雅得扩展规范

项目实践】SpringBoot三招组合拳,手把手教你打出优雅的后端接口。我们做到了:

通过Validator + 自动抛出异常来完成了方便的参数校验

通过全局异常处理 + 自定义异常完成了异常操作的规范

通过数据统一响应完成了响应数据的规范

多个方面组装非常优雅的完成了后端接口的协调,让开发人员有更多的经历注重业务逻辑代码,轻松构建后端接口

这样看上去好像挺完美的,很多地方做到了统一和规范。但!事物往往是一体两面的,统一和规范带来的好处自然不必多说,那坏处呢?坏处就是不够灵活

数据统一响应

不够灵活主要体现在哪呢,就是数据统一响应这一块。后端响应给前端的数据一共分为三个部分:

code:响应码,比如1000代表响应成功,1001代表响应失败等等

msg:响应信息,用来说明/描述响应情况

data:响应的具体数据

我们通过响应码枚举做到了code和msg的统一,无论怎样我们只会响应枚举规定好的code和msg。我天真的以为这样就能满足所有应用场景了,直到我碰到了一位网友的提问:

想请问下如果我检验的每个参数对应不同的错误信息,即code,message都不同 这样该如何处理呢?因为这些错误码是有业务含义的,比如说手机号校验的错误码是V00001,身份证号错误码是V00002。

这一下把我问的有点懵,当时回答道validation参数校验失败的话可以手动捕捉参数校验异常对象,判断是哪个字段,再根据字段手动返回错误代码。我先来演示一下我所说的这种极为麻烦的做法:

手动捕捉异常对象

因为BindingResult对象里封装了很多信息,我们可以拿到校验错误的字段名,拿到了字段名后再响应对应的错误码和错误信息。在Controller层里对BindingResult进行了处理自然就不会被我们之前写的全局异常处理给捕获到,也就不会响应那统一的错误码了,从而达到了每个字段有自己的响应码和响应信息:

@PostMapping("/addUser") public ResultVO<String> addUser(@RequestBody @Valid User user, BindingResult bindingResult) { for (ObjectError error : bindingResult.getAllErrors()) { // 拿到校验错误的参数字段 String field = bindingResult.getFieldError().getField(); // 判断是哪个字段发生了错误,然后返回数据响应体 switch (field) { case "account": return new ResultVO<>(100001, "账号验证错误", error.getDefaultMessage()); case "password": return new ResultVO<>(100002, "密码验证错误", error.getDefaultMessage()); case "email": return new ResultVO<>(100003, "邮箱验证错误", error.getDefaultMessage()); } } // 没有错误则返回则直接返回正确的信息 return new ResultVO<>(userService.addUser(user)); }

我们故意输错参数,来看下效果:

【项目实践】后端接口统一规范的同时,如何优雅得扩展规范

嗯,是达到效果了。不过这代码一放出来简直就让人头疼不已。繁琐、维护性差、复用性差,这才判断三个字段就这样子了,要那些特别多字段的还不得起飞咯?

这种方式直接pass!

那我们不手动捕捉异常,我们直接舍弃validation校验,手动校验呢?

手动校验

我们来试试:

@PostMapping("/addUser") public ResultVO<String> addUser(@RequestBody User user) { // 参数校验 if (user.getAccount().length() < 6 || user.getAccount().length() > 11) { return new ResultVO<>(100001, "账号验证错误", "账号长度必须是6-11个字符"); } if (user.getPassword().length() < 6 || user.getPassword().length() > 16) { return new ResultVO<>(100002, "密码验证错误", "密码长度必须是6-16个字符"); } if (!Pattern.matches("^[a-zA-Z0-9_-]+@[a-zA-Z0-9_-]+(\\.[a-zA-Z0-9_-]+)+$", user.getEmail())) { return new ResultVO<>(100003, "邮箱验证错误", "邮箱格式不正确"); } // 没有错误则返回则直接返回正确的信息 return new ResultVO<>(userService.addUser(user)); }

我去,这还不如上面那种方式呢。上面那种方式至少还能享受validation校验规则的便利性,这种方式简直又臭又长。

那有什么办法既享受validation的校验规则,又能做到为每个字段制定响应码呢?不卖关子了,当然是有滴嘛!

还记得我们前面所说的BindingResult可以拿到校验错误的字段名吗?既然可以拿到字段名,我们再进一步当然也可以拿到字段Field对象,能够拿到Field对象我们也能同时拿到字段的注解嘛。对,咱们就是要用注解来优雅的实现上面的功能!

自定义注解

如果validation校验失败了,我们可以拿到字段对象并能够获取字段的注解信息,那么只要我们为每个字段带上注解,注解中带上我们自定义的错误码code和错误信息msg,这样就能方便的返回响应体啦!

内容版权声明:除非注明,否则皆为本站原创文章。

转载注明出处:https://www.heiqu.com/zyzfds.html