SpringBoot：如何优雅地进行响应数据封装、异常处理？

背景

越来越多的项目开始基于前后端分离的模式进行开发，这对后端接口的报文格式便有了一定的要求。通常，我们会采用JSON格式作为前后端交换数据格式，从而减少沟通成本等。

这篇文章，就带大家了解一下基于SpringBoot框架来封装返回报文以及统一异常处理。

报文基本格式

一般报文格式通常会包含状态码、状态描述（或错误提示信息）、业务数据等信息。在此基础上，不同的架构师、项目搭建者可能会有所调整。但从整体上来说，基本上都是大同小异。

在SpringBoot项目中，通常接口返回的报文中至少包含三个属性：

• code：请求接口的返回码，成功或者异常等返回编码，例如定义请求成功。

• message：请求接口的描述，也就是对返回编码的描述。

• data：请求接口成功，返回的业务数据。

示例报文如下：

{
  "code":200,
  "message":"SUCCESS",
  "data":{
    "info":"测试成功"
  }
}

在上述报文格式中，不同的设计者是会有一些分歧的，特别是code值的定义。如果完全基于RESTful API设计的话，code字段可能就不需要存在了，而是通过HTTP协议中提供的GET、POST、PUT、DELETE操作等来完成资源的访问。

但在实践中，不论是出于目前国内大多数程序员的习惯，还是受限于HTTP协议提供的操作方法的局限性，很少完全遵照RESTful API方式进行设计。通常都是通过自定义Code值的形式来赋予它业务意义或业务错误编码。

虽然可以不用完全遵守RESTful API风格来定义Code，在Code值的自定义中，也存在两种形式：遵循HTTP状态码和自主定义。

像上面的示例，用200表示返回成功，这就是遵循HTTP响应状态码的形式来返回，比如还有其他的400、401、404、500等。当然，还有完全自主定义的，比如用0表示成功，1表示失败，然后再跟进通用编码、业务分类编码等进行定义。

在此，笔者暂不评论每种形式的好坏，只列举了常规的几种形式，大家了解对应的情况，做到心中有数，有所选择即可。

响应参数封装实践

创建一个SpringBoot项目，并引入Lombok依赖（精简代码），对应的核心依赖如下：

    <dependencies>
        <dependency>
            <groupId>org.springframework.boot</groupId>
            <artifactId>spring-boot-starter-web</artifactId&