用 SpringBoot 实现简单的接口
上篇文章已经介绍了 SpringBoot 的基本使用过程 ，本文主要介绍用那篇文章中配置好的SpringBoot工程实现简单的接口。
最终工程目录是下面这样：
这是个简陋的目录结构，前尺仅供我们参考，其中主要分为四类：
最后还有一个..Application类，系统默认生成，不需要处理。
可以通过浏览器、PostMan调用以上写好的两个接口，来测试一下接口是否正常。慎悔纳在调用时注意宽没检查IP地址、端口、接口名和参数是否设置正确。
SpringBoot 规范接口开发流程
UserService
这种写法每次都要在controller层传入BindingResult，很不方便，接下来用敏罩粗自动抛出异常的方式去进一步优化
这时候后端桥镇已经引发了 MethodArgumentNotValidException 异常，并且前端收到的数据如下
后端直接将整个错误对象相关信息都响应给前端了，这是因为虽然引发了异常，但是我们没有去对其进行处理，所以走了SpringBoot默认的异常处理流程，现在开始进行全局异常处理
自定义异常的好处
还能在全局异常处理中处理Exception异常，这样无论遇到什么Exception都能够统一返回给前端，不过这种一般建议是在项目上线之前才这样做，开发的时候为了方便调试还是不太建议这样做
写一个新的api，返回的类型不再是ResultVo，而是直接闷亩返回实体类对象，这样就会走beforeBodyWrite方法去包装，然后真正返回给前端的还是ResultVO，这样做的目的就是可以省去我们自己手动封装数据到ResultVO的过程
效果
上面实体类中，id字段没有加上自定义注解，所以会走统一的VALIDATE_FAILED封装的响应体，而其他字段都加上了自定义注解，所以遇到字段校验出错时就会用自定义注解中的errcode和errmsg去封装返回
瞧瞧人家用SpringBoot写的后端API接口，那叫一个优雅
假设实现一个注册用户的功能，在controller 层，他会先进行校验参数，如下：
以上代码有什么问题嘛？ 其实没什么问题，就是校验有点辣眼睛 。正常的添加用户业务还没写，参数校验就一大堆啦。假设后来，又接了一个需求：编辑用户信息。实现编辑用户信息前，也是先校验信息，如下：
我们可以使用注解的方式，来进行参数校验，这样代码更加简洁，也方便统一管理。实际上， spring boot 有个 validation 的组件，我们可以拿来即用。引入这个包即可：
引入包后，参数谨卜升校验就非常简洁啦，如下：
然后在 UserParam 参数对象中，加入 @Validated 注解哈，把错误信息接收到 BindingResult 对象，代码如下：
如果你在你们项目代码中，看到controller 层报文返回结果，有这样的：
也有这样的：
显然，如果接口返回结果不统一，前端处理就不方便，我们代码也不好维护。再比如有的人喜欢用 Result 处理结果， 有点人 喜欢用 Response 处理结果，可以想象一下，这些代码有多乱。
所以作为后端开发，我们项目的响应结果，需要 统一标准的返回格式 。一般一个标准的响应报文对象，都有哪些属性呢？
响应状态码一般用枚举表示哈：
因为返回的数据类型不是确定的，我们可以使用泛型，如下：
有了统一的响应体，我们就可以优化一下controller 层的代码啦：
日常开发中，我们一般都是自定义祥老统一的异常类，如下：
在controller 层，很可能会有类似代码：
这块代码，没什么问题哈，但是如果 try...catch 太多，不是很优雅。
可以借助注解 @RestControllerAdvice ，让代码更优雅。 @RestControllerAdvice 是一个应用于 Controller 层的切面注解，它一般配合 @ExceptionHandler 注解一起弊拍使用，作为项目的全局异常处理。我们来看下demo代码哈。
还是原来的 UserController ，和一个会抛出异常的userService的方法，如下：
我们再定义一个全局异常处理器，用 @RestControllerAdvice 注解，如下：
我们有想要拦截的异常类型，比如想拦截 BizException 类型，就新增一个方法，使用 @ExceptionHandler 注解修饰，如下：