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

首先我们自定义一个注解:

/** * @author RC * @description 自定义参数校验错误码和错误信息注解 */ @Retention(RetentionPolicy.RUNTIME) @Target({ElementType.FIELD}) // 表明该注解只能放在类的字段上 public @interface ExceptionCode { // 响应码code int value() default 100000; // 响应信息msg String message() default "参数校验错误"; }

然后我们给参数的字段上加上我们的自定义注解:

@Data public class User { @NotNull(message = "用户id不能为空") private Long id; @NotNull(message = "用户账号不能为空") @Size(min = 6, max = 11, message = "账号长度必须是6-11个字符") @ExceptionCode(value = 100001, message = "账号验证错误") private String account; @NotNull(message = "用户密码不能为空") @Size(min = 6, max = 11, message = "密码长度必须是6-16个字符") @ExceptionCode(value = 100002, message = "密码验证错误") private String password; @NotNull(message = "用户邮箱不能为空") @Email(message = "邮箱格式不正确") @ExceptionCode(value = 100003, message = "邮箱验证错误") private String email; }

然后我们跑到我们的全局异常处理来进行操作,注意看代码注释:

@RestControllerAdvice public class ExceptionControllerAdvice { @ExceptionHandler(MethodArgumentNotValidException.class) public ResultVO<String> MethodArgumentNotValidExceptionHandler(MethodArgumentNotValidException e) throws NoSuchFieldException { // 从异常对象中拿到错误信息 String defaultMessage = e.getBindingResult().getAllErrors().get(0).getDefaultMessage(); // 参数的Class对象,等下好通过字段名称获取Field对象 Class<?> parameterType = e.getParameter().getParameterType(); // 拿到错误的字段名称 String fieldName = e.getBindingResult().getFieldError().getField(); Field field = parameterType.getDeclaredField(fieldName); // 获取Field对象上的自定义注解 ExceptionCode annotation = field.getAnnotation(ExceptionCode.class); // 有注解的话就返回注解的响应信息 if (annotation != null) { return new ResultVO<>(annotation.value(),annotation.message(),defaultMessage); } // 没有注解就提取错误提示信息进行返回统一错误码 return new ResultVO<>(ResultCode.VALIDATE_FAILED, defaultMessage); } }

这里做了全局异常处理,那么Controller层那边就只用专心做业务逻辑就好了:

@ApiOperation("添加用户") @PostMapping("/addUser") public String addUser(@RequestBody @Valid User user) { return userService.addUser(user); }

我们来看下效果:

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

可以看到,只要加了我们自定义的注解,参数校验失败了就会返回注解的错误码code和错误信息msg。这种做法相比前两种做法带来了以下好处:

方便。从之前一大堆手动判断代码,到现在一个注解搞定

复用性强。不单单可以对一个对象有效果,对其他受校验的对象都有效果,不用再写多余的代码

能够和统一响应码配合。前两种方式是要么就对一个对象所有参数用自定义的错误码,要么就所有参数用统一响应码。这种方式如果你不想为某个字段设置自定义响应码,那么不加注解自然而然就会返回统一响应码

简直不要太方便!这种方式就像在数据统一响应上加了一个扩展功能,既规范又灵活!

当然,我这里只是提供了一个思路,我们还可以用自定义注解做很多事情。比如,我们可以让注解直接加在整个类上,让某个类都参数用一个错误码等等!

绕过数据统一响应

上面演示了如何让错误码变得灵活,我们继续进一步扩展。

全局统一处理数据响应体会让所有数据都被ResultVO包裹起来返还给前端,这样我们前端接到的所有响应都是固定格式的,方便的很。但是!如果我们的接口并不是给我们自己前端所用呢?我们要调用其他第三方接口并给予响应数据,别人要接受的响应可不一定按照code、msg、data来哦!所以,我们还得提供一个扩展性,就是允许绕过数据统一响应!

我想大家猜到了,我们依然要用自定义注解来完成这个功能:

@Retention(RetentionPolicy.RUNTIME) @Target({ElementType.METHOD}) // 表明该注解只能放在方法上 public @interface NotResponseBody { }

只要加了这个注解的方法,我们就不做数据统一响应处理,返回类型是啥就是返回的啥

@GetMapping("/getUser") @NotResponseBody public User getUser() { User user = new User(); user.setId(1L); user.setAccount("12345678"); user.setPassword("12345678"); user.setEmail("123@qq.com"); return user; }

我们接下来再数据统一响应处理类里对这个注解进行判断:

@RestControllerAdvice(basePackages = {"com.rudecrab.demo.controller"}) public class ResponseControllerAdvice implements ResponseBodyAdvice<Object> { @Override public boolean supports(MethodParameter returnType, Class<? extends HttpMessageConverter<?>> aClass) { // 如果接口返回的类型本身就是ResultVO那就没有必要进行额外的操作,返回false // 如果方法上加了我们的自定义注解也没有必要进行额外的操作 return !(returnType.getParameterType().equals(ResultVO.class) || returnType.hasMethodAnnotation(NotResponseBody.class)); } ... }

好,我们来看看效果。没加注解前,数据是被响应体包裹了的:

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

方法加了注解后数据就直接返回了数据本身:

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

非常好,在数据统一响应上又加了一层扩展。

总结

经过一波操作后,我们从没有规范到有规范,再从有规范到扩展规范:

没有规范(一团糟) --> 有规范(缺乏灵活) --> 扩展规范(Nice)

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

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