远程接口设计

近来使用了各个系统的接口，也设计了一些接口供他人使用。吸取一些吐槽跟被吐槽间的点，做点总结。

1. 提供干净的依赖包

在使用接口的时候，最痛苦的莫过于依赖包的冲突。解决包冲突是一个十分费时且无聊的工作，并且有些冲突在启动时不会暴露，最后造成线上故障。而有些冲突压根就不能解决，导致接口无法引入。

2. 使用包装类

基本类型无法提供Null语义。很多序列化框架对于基本类型会将Null解析成0，而0与Null是两种不同语义。同时，数据库状态，枚举值建议也不要定义成0

3. 不要使用过多参数

一个接口参数过多是非常难以理解跟扩展的，对于这种情况一般使用Request对象包装参数，考虑后续可扩展性，也可在Request加以一个扩展Map字段

Request{
    ...
   Map attributes;
}

4. 返回值

一个好的接口返回值非常重要，如下面的仓库提供的发货接口

/**返回一个快递单号**/
Long deliveryOrder(Long orderId)

这个接口的返回值有以下几个问题：

1. 接口返回Null，通常代表业务执行失败。那么失败的原因没有上抛，不方便调用者后续处理，也无法进行错误统计监控
2. 接口出错的情况有很多，有框架层面，有系统层面，也有业务层面，统统使用异常往上抛，使用不方便
3. 如果这个接口调用失败， 那么调用者要不要进行重试。如果接口没幂等，重复调用会出现多次发货，造成资损

稍做修改返回Result对象

Result<Long> deliveryOrder(Long orderId)

Result<T>{
   T getData()
   String getErrorCode()
   String getErrorMsg()
   boolean isSuccess()
   boolean canRetry()
}

1. isSuccess: 表示业务是否执行成功。其他框架异常通过异常抛出
2. 提供错误码让调用者可以根据不通错误码进行不通处理，同时也可以配置错误码监控大盘，方便统计报警
3. canRetry: 某些业务错误，压根就没必要进行重试，可提供此函数供调用者使用。

5. 幂等

现有的RPC框架基本都会进行超时重试，如果接口不幂等的话，结果不可想象

6. 使用DTO

系统分层设计后，为了各层之间的松耦合可能会设计各种DO，VO，BO，甚至还有View层Query对象，DAO层Query对象，让人防不胜防。但是，当对外提供接口时，尽量使用DTO包装。使用DTO可以在修改系统内部数据结构的时候不影响对外接口，同时也可以保证数据安全

7. 使用client包装

对于一些不合规范的老接口，可以使用Client也就是装饰模式进行包装

8. 日志

接口异常路径必须打上日志，写上错误原因并且带上请求参数。如果条件允许，也可以在入口处打印接口被调用并且附上请求参数