在挪动互联网，分布式、微服务流行的明天，当初我的项目绝大部分都采纳的微服务框架，前后端拆散形式，（题外话：前后端的工作职责越来越明确，当初的前端都称之为大前端，技术栈以及生态圈都曾经十分成熟；以前后端人员瞧不起前端人员，那当初后端人员要重新认识一下前端，前端曾经很成体系了）。

个别零碎的大抵整体架构图如下：

须要阐明的是，有些小伙伴会回复说，这个架构太简略了吧，太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 - 资源（网页等）被永恒转移到其它URL404 - 申请的资源（网页等）不存在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