评估API经纪商时应检查什么
定义“API经纪商”以及使用它时的变化
API经纪商是一种市场接入或交易执行服务，您通过编程方式（通过应用程序编程接口）连接，而不是使用手动交易界面。关键区别在于，您的系统需要负责将您的意图（订单指令）转化为实际请求，处理响应，并对错误做出反应。
为了客观地评估API经纪商，请将问题分为两个层面：
- 集成机制（稳定、可测试）：认证如何工作、如何发送请求、响应的格式，以及如何解释订单和执行状态。
- 市场和提供商条件（可变）：在价格波动、流动性不足、网络延迟以及提供商端的执行规则和成本下会发生什么。
如果您只关注“API”部分，可能会忽略最重要的不确定性——执行质量和在压力下的运营行为。
检查清单：您可以验证的集成机制
采用基于证据的方法：索取或检查文档，然后通过受控示例进行测试。
-
认证和账户范围：确认使用的凭证类型、访问授权方式，以及API密钥是否可根据权限进行限制（例如只读与交易权限）。
-
请求/响应模型：检查API如何表示订单——订单类型、有效时间、必填字段，以及响应的确切结构。定义您可以依赖的状态，并明确哪些字段在临时故障期间可能缺失。
-
幂等性和重复控制：确定API如何防止或解决重复提交（例如超时后的重试）。您的系统应能避免意外的重复订单。
-
订单和执行生命周期映射：验证“已接受”、“已成交”、“已拒绝”、“已取消”或等效状态的含义。一个重大风险是状态不一致——您的系统可能认为订单仍在执行中，而经纪商已拒绝该订单。
-
速率限制和限流行为：检查文档中的限制以及指示限流的响应。规划您的代码在收到限制或背压信号时的行为。
-
数据产品和时间戳：如果API提供报价、交易或账户事件，请澄清时间戳的含义（服务器时间 vs 本地时间）以及更新频率的假设。没有这些信息，您无法将延迟与市场变动区分开。
-
错误处理和重试策略：确认API如何传达错误（HTTP/网络 vs 应用层）。您的测试应将故障分类为“可安全重试”、“使用幂等性重试”和“不应重试”。
证据和示例：如何在不假设结果的情况下进行测试
由于结果随条件变化，请使用测量您系统行为的测试。
- 黑盒集成测试：发送少量明确定义的订单，并确认您的内部状态机与API报告的生命周期一致。
- 超时和重试模拟（明确假设）：假设您的网络调用在给定阈值后可能超时（为您的环境选择一个阈值）。然后验证重试是否会导致重复，或幂等性密钥（如果支持）是否能防止重复。
- 部分成交场景（明确假设）：假设市场可能无法完全满足您的订单量。测试您如何检测剩余数量以及后续更新如何传递。
- 事件顺序检查：记录API回调/事件的顺序，并与您的代码预期进行比较。一种故障模式是乱序更新，这可能会破坏您订单跟踪中的假设。
对于每个测试，请记录：请求ID、时间戳（带时区/来源）、响应载荷以及最终对账结果。
局限性和风险：至少一种重大故障模式
即使文档看起来清晰，也存在重要限制：
- 运营故障：网络中断、API停机或服务降级可能导致响应丢失或状态更新延迟。您的自动化系统必须在不确定性期间安全运行。
- 部分成交和执行可变性：即使集成正确，实际成交仍取决于当时的可用流动性和执行机制。
- 状态不匹配（重大故障模式）：您的系统可能显示“正在执行”的订单，而经纪商已拒绝或取消。这可能在超时、重试或不一致的事件传递后发生。
- 成本和滑点不确定性：执行结果可能与历史关系不同，因为成本和执行质量随条件变化。
因此，评估的目的不是预测，而是能够对账实际发生的情况并检测不匹配。
自动化前的验证和后续问题
在依赖API自动化之前，请确保对以下问题有清晰、可独立验证的答案：