返回结果尽量使用状态码、提示信息形式

我们写的RPC接口尽量使用如下 Response<T> 的形式返回结果，结果中至少要包含

code：响应状态
message：错误提示信息。

理论上我们不应该把我们的异常堆栈信息暴露给第三方调用者，因为他们可以从堆栈信息中看出我们使用了哪些工具，使用了那些jar等，尤其是有些sql异常会打印数据库、表、以及表的一些字段还有sql语句，这些被对方知道后，可能会引起不必要的安全问题。例如对方发现你使用了某个有漏洞的包，然后就定向攻击，让你服务崩溃；会对你的服务进行sql注入获取一些敏感信息。而且这也不符合接口设计原则中的"最少知道原则"。

再有我们设计接口的时候，需要返回一些友好的异常提示，让调用者在看到后能够方便和快速的定位问题，知道异常的原因。例如

参数异常：您输入的xxx必须是整数。
业务异常：数据已经处理，请勿重复操作。

我们抛出的异常应该是可读的、友好的、明确的以及完整的话。

还有最好我们要返回一个异常的状态码，这个异常的状态码，至少算是一种归类，类似于http的状态码一样，200代表成功，非200代表失败，不同的状态码代表不同的异常分类等。

/**
 * @author chenshang
 */
@Data
@ApiModel(value = "Response", description = "响应")
public class Response<T> {
    /**
     * 响应状态 0=成功,其他代表失败
     */
    @ApiModelProperty("响应状态")
    private int code;
    /**
     * when code == 0 then msg=success
     * when code != 0 then msg=错误信息
     */
    @ApiModelProperty("msg")
    private String msg;
    /**
     * 响应数据
     */
    @ApiModelProperty("响应数据")
    private T data;
}

对于分页的场景,相较于上面的返回值


/**
 * 分页响应
 *
 * @author chenshang
 * @date 2022/06/11
 */
@Data
@ApiModel(value = "PageResponse", description = "分页响应")
public class PageResponse<T> {
    @ApiModelProperty("响应结果")
    private T list;
    @ApiModelProperty("当前页")
    private int curPage;
    @ApiModelProperty("每页多少数据")
    private int numPerPage;
    @ApiModelProperty("总数量")
    private long totalNum;
    @ApiModelProperty("总页数")
    private int totalPage;
}

需要专门的层封装第三方接口

分层结构数见不鲜，好处我就不过渡赘述了

这一层应该是对第三方接口的一个简单的封装，对方有一个方法，我么这里应该就有一个方法与之对应（当然只对接我们需要的），不应该耦合过多的业务逻辑，但是有时候其实也可以把service都共用的一些逻辑放到这一层，但是随着这样功能的函数越来越多，我们还是需要一个单独或者多个service层对其进行业务逻辑的封装。