在移动互联、微服务盛行的今天，现在项目绝大部分都采用的微服务框架，其实API接口就相当于一个方法或者函数，只不过通过http来访问。API接口也需要参数，也会返回结果。

一般系统大致架构如下：

调用接口的步骤：
(一)客户端请求接口的URL。
(二)传入接口需要的参数param。
(三)接口返回调用的结果(数据)。
(四)客户端解析结果。

接口交互

前端和后端进行交互，前端按照约定请求URL路径，并传入相关参数，后端服务器接收请求，进行业务处理，返回数据给前端。

1、需要自己创建一个HttpUtil类。下面以自己创建的HttpUtil为例。
HttpUtil类一般包括：doGet和doPost方法
public static String doGet(String url, Map param){}
public static String doPost(String url, Map param){}

2、创建url和访问参数param等：
url即是要访问接口的地址，参数param即是接口需要的参数。
参数param一般是以map的形式传递。
接口地址：
String requestUrl = “……”;
params用于存储要请求的参数：
Map params = new HashMap();
我们请求的字符串
params.put(“info”,info);

3、通过HttpUtil类，使用doGet和doPost方法请求URL，传输参数param，从而调用接口API。

下面便是一个executePost(同doPost)的详细内容：(使用了org.apache.http中的内容)

4、调用API后，一般会得到返回的结果，最后是根据接口返回数据格式来解析数据。

后端服务器是如何实现把数据返回给前端？

返回格式

{
  #返回状态码
  code:integer,
  #返回信息描述
  message:string,
  #返回值
  data:object
}

CODE状态码

状态码代表了服务器在处理请求的过程中有错误或者异常状态发生，也有可能是服务器意识到以当前的软硬件资源无法完成对请求的处理。除非这是一个HEAD 请求，否则服务器应当包含一个解释当前错误状态以及这个状况是临时的还是永久的解释信息实体。浏览器应当向用户展示任何在当前响应中被包含的实体。

如接口要返回用户权限异常，我们加一个状态码为101吧，下一次又要加一个数据参数异常，就加一个102的状态码。这样虽然能够照常满足业务，但状态码太凌乱了

我们应该可以参考HTTP请求返回的状态码

：下面是常见的HTTP状态码：
200 - 请求成功
301 - 资源(网页等)被永久转移到其它URL
404 - 请求的资源(网页等)不存在
500 - 内部服务器错误

我们也可以参考这样的设计，这样的好处就是把错误类型归类到某个区间内，但是如果区间不够，可以设计成4位数。

#1000～1999 区间表示参数错误
#2000～2999 区间表示用户错误
#3000～3999 区间表示接口异常

对于前端开发人员在得到返回值后，就根据状态码就可以知道，大概是什么错误，而且也可以再根据message相关的信息描述，可以快速定位。

Message

Message字段相对理解比较简单，就是在发生错误时，如何友好的进行提示。一般的设计是和code状态码一起设计。

再举一个例子：

状态码和信息就会一一对应，比较好维护。

Data

返回数据体，JSON格式，是一种根据不同的业务又不同的JSON体。并且需要我们要设计一个返回体类Result

控制层Controller

我们需要在controller层处理业务请求，并返回给前端，例如下面

我们得到关于order的对象之后，我们是用的Result构造方法进行包装赋值，然后进行返回。不知道你有么有发现，构造方法这样的包装是不是很麻烦，我们可以优化一下。

美观美化

我们可以在Result类中，加入静态方法，

那我们来优化一下Controller

优雅优化

我们在以上讲述了关于Result类中增加了静态方法，使得业务处理代码简洁了。但还是有这样几个问题：

1、关于每个方法的返回都是Result封装对象，没有业务含义。

2、而且在业务代码中，成功的时候我们调用Result.success，异常错误调用Result.failure。就会显得有点多余。

3、以上判断id是否为null，其实我们就只需要使用validate做校验就可以了，并不需要太麻烦了。

最好的方式就是直接返回真实业务对象，最好不要改变之前的业务方式，如下图

以下是如何实现的方案

实现方案

在这里，我们需要做几个事情

1、首先我们需要自定义一个注解@ResponseResult，表示这个接口返回的值需要包装一下。

2、然后是关于拦截请求的，判断此请求是否需要被@ResponseResult注解。

3、还有核心步骤就是实现接口ResponseBodyAdvice和@ControllerAdvice，并且对返回值进行判断，如果需要，就对返回值进行重写。

注解类

用来标记方法的返回值，我们是否需要包装

拦截器

运行的时候，解析@ResponseResult注解(即拦截请求，是否此请求返回的值需要包装)

此代码核心思想，就是获取此请求，设置一个属性标记。

重写返回体

重写Controller

在控制器类上或者方法体上加上自定义注解@ResponseResult，这样就可以了。既简洁，又优雅。

这个方案还有没有别的优化空间，当然是有的。如：每次请求都要反射一下，获取请求的方法是否需要包装，其实可以做个缓存，就可以，我们省去了大量繁杂的步骤。

云码教育

微信号｜云码技术栈

新浪微博｜云码技术栈