评估API接入时应检查什么
以实际术语定义API接入
API接入是指一种软件接口，允许一个系统通过发送结构化请求并接收结构化响应，来从另一个系统请求数据或执行操作。在交易或市场数据场景中，这通常包括认证（证明你有权连接）、授权（你被允许执行的操作）以及数据交换（报价、订单、持仓或账户相关信息）。
在评估API接入时，需区分两个方面：
- 稳定机制：接口的工作方式（请求/响应流程、格式、限制、时间戳）。
- 可变条件：该接口在特定使用场景下的表现（网络延迟、服务商正常运行时间、执行行为，以及任何司法管辖区或政策限制）。
一个常见错误是将一次样本响应或一次成功集成就视为证据，认为API在高使用率、系统中断或市场快速波动时仍会保持相同行为。
技术验证内容（集成检查清单）
从通常决定集成是否成功的“基础架构”细节开始：
- 认证与授权
- 确认认证方式，以及凭证的存储和轮换机制。
- 验证API密钥/令牌的权限范围（例如，是否只能读取市场数据，或也可管理订单和账户数据）。
- 数据与请求范围
- 明确哪些数据字段可用，并确认是否符合你的需求。
- 检查响应是否包含时间信息，以及使用的时间基准（例如服务器时间 vs. 本地时间）。
- 消息格式与模式
- 验证请求和响应的结构（字段名、类型、必填与可选字段）。
- 确认分页、过滤和批量处理的表示方式。
- 速率限制与限流
- 检查文档中说明的速率限制，以及API如何提示超出限制。
- 确保你的客户端能够退避、安全重试，并避免意外的请求洪峰。
- 订单与状态处理（如适用）
- 对于交易相关API，确认系统如何报告订单确认、成交、拒绝和变更。
- 定义当更新乱序到达时，如何协调“期望状态”与“报告状态”。
应查找的证据或文档：清晰的API文档，明确说明端点、模式、错误代码和限制。没有这些，你将无法独立验证接口的行为。
通过可复现示例测试行为
要将文档转化为证据，需在明确假设下进行受控测试：
- 假设一个基准网络延迟，并发送已知的请求序列。
- 记录请求时间戳、响应时间戳和关联标识符（如提供）。
- 验证相同输入是否产生一致的输出结构，即使数值发生变化。
需主动排查的实质性故障模式：
- 部分失败：API可能对一个请求返回成功，但后续请求失败，或接受请求后通过异步更新报告错误。你的系统必须能处理预期与API报告之间的不一致。
还需测试：
- 错误响应：API如何响应无效参数、过期认证或超出限制？
- 重连机制：临时网络中断后会发生什么？
- 幂等性：如果你重试请求，是否会创建重复项，或能安全避免重复操作？
需考虑的限制与风险
API接入评估应包含对实际运营不确定性的考量：
- 正常运行时间与延迟会变化：接口在测试中可能表现完美，但在高负载或事故期间仍可能退化。
- 市场状况可能变化：波动性升高时，正确的时间处理和稳健的错误恢复变得更加重要。
- 成本与资源使用可能受限：许多API存在基于使用量的限制（速率、带宽或不同层级），可能影响你工作负载的性能和可用性。
一个与时间无关的限制：历史行为不能保证未来结果。因此，应将测试视为仅在你定义的假设和条件下对当前行为的证据。
验证标准与后续问题
使用一个“可验证就绪”检查清单，确保无需依赖承诺即可回答：
- 你能否将每个所需功能（数据读取、账户读取、订单管理）映射到具体的文档端点和权限？
- 你能否从文档中描述确切的速率限制，以及预期的限流和错误信号？
- 你能否解释当更新延迟、乱序到达或与先前假设冲突时，将如何协调状态？
- 你是否有针对重试、幂等性和部分失败的错误处理计划？