一个接口一般对参数（请求数据）都会进行安全校验参数校验的重要性自然不必多说，那么如何对参数进行校验就有讲究了

首先我们来看一下最常见的做法，就是在業务层进行参数校验： 

 

 再来看一下接口的响应数据：
 
 

 
 
 

 这样是不是方便很多不难看出使用Validator校验有如下几个好处：
 
 

1. 简化代码，之前业务层那麼一大段校验代码都被省略掉了
2. 使用方便，那么多校验规则可以轻而易举的实现比如邮箱格式验证，之前自己手写正则表达式要写那麼一长串还容易出错，用Validator直接一个注解搞定（还有更多校验规则注解，可以自行去了解哦）
3. 减少耦合度使用Validator能够让业务层只关注业務逻辑，从基本的参数校验逻辑中脱离出来

 

 使用Validator+ BindingResult已经是非常方便实用的参数校验方式了，在实际开发中也有很多项目就是这么做的不過这样还是不太方便，因为你每写一个接口都要添加一个BindingResult参数然后再提取错误信息返回给前端。这样有点麻烦并且重复代码很多（尽管可以将这个重复代码封装成方法）。我们能否去掉BindingResult这一步呢当然是可以的！
 
 

 

 我们完全可以将BindingResult这一步给去掉：
 
 

 

 看一下如果响应正确返回嘚是什么效果：
 
 

 
 
 

 这样无论是正确响应还是发生异常，响应数据的格式都是统一的十分规范！
 
 

 数据格式是规范了，不过响应码code和响应信息msg還没有规范呀！大家发现没有无论是正确响应，还是异常响应响应码和响应信息是想怎么设置就怎么设置，要是10个开发人员对同一个類型的响应写10个不同的响应码那这个统一响应体的格式规范就毫无意义！所以，必须要将响应码和响应信息给规范起来
 
 

 

 要规范响应体Φ的响应码和响应信息用枚举简直再恰当不过了，我们现在就来创建一个响应码枚举类：
 
 

 // 注意哦这里是直接返回的User类型，并没有用ResultVO进行包装

 

 然后我们来看下响应数据：
 
 

 
 
 

 成功对数据进行了包装！
 
 

注意：beforeBodyWrite方法里包装数据无法对String类型的数据直接进行强转所以要进行特殊处理，這里不讲过多的细节有兴趣可以自行深入了解。

 

 自此整个后端接口基本体系就构建完毕了
 
 

• 通过Validator + 自动抛出异常来完成了方便的参数校验
• 通過全局异常处理 + 自定义异常完成了异常操作的规范
• 通过数据统一响应完成了响应数据的规范
• 多个方面组装非常优雅的完成了后端接口的协調让开发人员有更多的经历注重业务逻辑代码，轻松构建后端接口