一个完善的 API 流程标准（草图）

目的

1. 保证 API 自己是安全的，不会受到如下（包括但不限于）手段的攻击：

   1. 重入攻击；

2. 保证调用方是能够管理的，包括但不限于：

   1. 来源模块是可控的；

   2. 来源设备是可控的；

   3. 调用频率是可控的；

3. 整个调用链条是可追踪的，即从接入层一直到数据层是相关的；

设计思路

概念

1. APPID: 标明调用方的惟一标识；

2. JWT: Json Web Token，一种标准化的对称加密机制；

3. JWT-Signature: 使用 JWT 加密后的密文；

4. LOGID: 由接入层生成的调用链条惟一标识；

思路说明

1. 调用方在使用 API 时，须要先进行受权申请，获取惟一的 APPID 及 APPSECRET；

2. 调用方须要报备调用设备的请求 ip；

3. 调用方须要申请必定的请求频率（在使用默认值的状况下，这个步骤能够忽略）；

4. 调用方在请求 API 时，须要进行以下步骤：

   1. 将下游传给本身的 LOGID 做为调用链条的惟一标识，继续向上游进行传递，若是调用方是接入层，则按必定规则生成一个惟一串做为本次调用链条的惟一 LOGID（这个步骤是为了完成目的 3）；

   2. 使用申请到的 APPSECRET 对包括当前请求时间 + 请求参数的组合的签名 进行 JWT 加密；

   3. 将 APPID 和 第 2) 步生成的签名一并传递给上游；

5. 服务提供方在接到请求时，按如下步骤验证其合法性：

   1. APPID、JWT-Signature、LOGID 是否存在，不然不合法；

   2. APPID 是否被受权访问该 API，不然不合法；

   3. 实际请求 ip 是否和 APPID 报备的请求 ip 匹配，不然不合法；

   4. 根据 APPID 对应的 APPSECRET 解密 JWT-Signature 是否正确，不然不合法；

   5. 请求时间是否超时，不然不合法；

   6. 请求参数的组合的签名是否一致，不然不合法；

   7. 请求频率是否小于分配给该 APPID 的频率限制，不然不合法；

   8. 请求频率是否小于该 API 的全局频率限制，不然不合法；

6. 在服务提供方记录日志及请求其上游时，将 LOGID 进行记录及传递；