一个完善的 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 进行记录及传递；