在挪动互联网，分布式、微服务流行的明天，当初我的项目绝大部分都采纳的微服务框架，前后端拆散形式，（题外话：前后端的工作职责越来越明确，当初的前端都称之为大前端，技术栈以及生态圈都曾经十分成熟；以前后端人员瞧不起前端人员，那当初后端人员要重新认识一下前端，前端曾经很成体系了）。
个别零碎的大抵整体架构图如下：
须要阐明的是，有些小伙伴会回复说，这个架构太简略了吧，太 low 了，什么网关啊，缓存啊，消息中间件啊，都没有。因为老顾这篇次要介绍的是 API 接口，所以咱们聚焦点，其余的模块小伙伴们自行去补充。
接口交互
前端和后端进行交互，前端依照约定申请 URL 门路，并传入相干参数，后端服务器接管申请，进行业务解决，返回数据给前端。
针对 URL 门路的 restful 格调，以及传入参数的公共申请头的要求（如：app_version,api_version,device 等），老顾这里就不介绍了，小伙伴们能够自行去理解，也比较简单。
着重介绍一下后端服务器如何实现把数据返回给前端？
返回格局
后端返回给前端咱们个别用 JSON 体形式，定义如下：
{
#返回状态码
code:integer,
#返回信息形容
message:string,
#返回值
data:object
}CODE 状态码
code 返回状态码，个别小伙伴们是在开发的时候须要什么，就增加什么。
如接口要返回用户权限异样，咱们加一个状态码为 101 吧，下一次又要加一个数据参数异样，就加一个 102 的状态码。这样尽管可能照常满足业务，但状态码太凌乱了
咱们应该能够参考 HTTP 申请返回的状态码
：上面是常见的 HTTP 状态码：200 - 申请胜利
301 - 资源（网页等）被永恒转移到其它 URL
404 - 申请的资源（网页等）不存在
500 - 外部服务器谬误
咱们能够参考这样的设计，这样的益处就把谬误类型归类到某个区间内，如果区间不够，能够设计成 4 位数。
#1000～1999 区间示意参数谬误
#2000～2999 区间示意用户谬误
#3000～3999 区间示意接口异样这样前端开发人员在失去返回值后，依据状态码就能够晓得，大略什么谬误，再依据 message 相干的信息形容，能够疾速定位。
Message
这个字段绝对了解比较简单，就是产生谬误时，如何敌对的进行提醒。个别的设计是和 code 状态码一起设计，如
再在枚举中定义，状态码
状态码和信息就会一一对应，比拟好保护。
Data
返回数据体，JSON 格局，依据不同的业务又不同的 JSON 体。
咱们要设计一个返回体类 Result
管制层 Controller
咱们会在 controller 层解决业务申请，并返回给前端，以 order 订单为例
咱们看到在取得 order 对象之后，咱们是用的 Result 构造方法进行包装赋值，而后进行返回。小伙伴们有没有发现，构造方法这样的包装是不是很麻烦，咱们能够优化一下。
好看优化
咱们能够在 Result 类中，退出静态方法，一看就懂
那咱们来革新一下 Controller
代码是不是比拟简洁了，也好看了。
优雅优化
下面咱们看到在 Result 类中减少了静态方法，使得业务解决代码简洁了。但小伙伴们有没有发现这样有几个问题：
1、每个办法的返回都是 Result 封装对象，没有业务含意
2、在业务代码中，胜利的时候咱们调用 Result.success，异样谬误调用 Result.failure。是不是很多余
3、下面的代码，判断 id 是否为 null，其实咱们能够应用 hibernate validate 做校验，没有必要在办法体中做判断。
咱们最好的形式间接返回实在业务对象，最好不要扭转之前的业务形式，如下图
这个和咱们平时的代码是一样的，十分直观，间接返回 order 对象，这样是不是很完满。那实现计划是什么呢？
实现计划
小伙伴们怎么去实现是不是有点思路，在这个过程中，咱们须要做几个事件
1、定义一个注解 @ResponseResult，示意这个接口返回的值须要包装一下
2、拦挡申请，判断此申请是否须要被 @ResponseResult 注解
3、外围步骤就是实现接口 ResponseBodyAdvice 和 @ControllerAdvice，判断是否须要包装返回值，如果须要，就把 Controller 接口的返回值进行重写。
注解类
用来标记办法的返回值，是否须要包装
拦截器
拦挡申请，是否此申请返回的值须要包装，其实就是运行的时候，解析 @ResponseResult 注解
此代码核心思想，就是获取此申请，是否须要返回值包装，设置一个属性标记。
重写返回体
下面代码就是判断是否须要返回值包装，如果须要就间接包装。这里咱们只解决了失常胜利的包装，如果办法体报异样怎么办？解决异样也比较简单，只有判断 body 是否为异样类。
怎么做全局的异样解决，篇幅起因，老顾这里就不做介绍了，只有思路理分明了，自行革新就行。
重写 Controller
在控制器类上或者办法体上加上 @ResponseResult 注解，这样就 ok 了，简略吧。到此返回的设计思路实现，是不是又简洁，又优雅。
总结
这个计划还有没有别的优化空间，当然是有的。如：每次申请都要反射一下，获取申请的办法是否须要包装，其实能够做个缓存，不须要每次都须要解析。当然整体思路理解，小伙伴们就能够在此基础下面自行扩大。谢谢！！！
起源：r6d.cn/tEvn