共计 2333 个字符，预计需要花费 6 分钟才能阅读完成。
公众号：MarkerHub，网站：https://markerhub.com
作者：里奥 ii
起源：r6d.cn/tEvn
在挪动互联网，分布式、微服务流行的明天，当初我的项目绝大部分都采纳的微服务框架，前后端拆散形式，（题外话：前后端的工作职责越来越明确，当初的前端都称之为大前端，技术栈以及生态圈都曾经十分成熟；以前后端人员瞧不起前端人员，那当初后端人员要重新认识一下前端，前端曾经很成体系了）。
个别零碎的大抵整体架构图如下：
❝
须要阐明的是，有些小伙伴会回复说，这个架构太简略了吧，太 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 了，简略吧。到此返回的设计思路实现，是不是又简洁，又优雅。
总结
这个计划还有没有别的优化空间，当然是有的。如：每次申请都要反射一下，获取申请的办法是否须要包装，其实能够做个缓存，不须要每次都须要解析。当然整体思路理解，小伙伴们就能够在此基础下面自行扩大。谢谢！！！
举荐浏览
太赞了，这个 Java 网站，什么我的项目都有！https://markerhub.com
这个 B 站的 UP 主，讲的 java 真不错！
太赞了！最新版 Java 编程思维能够在线看了！