验证与重试请求
概述
即使正确发送，服务器 API 请求也可能失败。诸如流量峰值、短暂中断、网络问题或上游服务缓慢之类的临时性问题都可能阻止成功响应。这些错误通常持续时间较短，且往往会自行解决。
遇到此类错误时立即失败会降低可靠性，而过于频繁地重试则可能使服务器过载。指数重试通过拉开重试尝试的间隔、每次增加延迟来解决这一问题。这给服务器留出恢复时间，提高成功几率，从而带来更稳定可靠的集成。
如何实现指数重试
本节定义了实现指数重试机制所预期的客户端行为。
步骤 1：正常发送请求
- 执行一次 API 请求
- 在首次尝试时不施加任何延迟
步骤 2：评估失败类型
如果请求失败，客户端必须确定：
- 是否收到了 HTTP 响应？
- 如果是，HTTP 状态代码是什么？
- 如果否，是否发生了网络或传输错误？
此分类决定了是否允许重试。
步骤 3：判断错误是否可重试
仅当以下所有条件均为真时才重试：
- 该失败被视为_瞬时性_的
- 稍后重试同一请求可能会成功
- 该请求可安全重试（幂等或受保护）
如果其中任何一个条件为假，则该请求必须失败，且不应尝试任何重试策略。
步骤 4：在重试前应用指数退避
当允许重试时：
- 在重试前等待
- 每次尝试时以指数方式增加等待时间
延迟必须：
- 从较小值开始（例如：500ms）
- 逐步增加（例如：每次请求翻倍）
- 设有合理的最大上限（例如：最多 10 分钟）
时间线示例
| 尝试次数 | 延迟 |
|---|---|
| 1 | 500 ms |
| 2 | 1 s |
| 3 | 2 s |
| 4 | 4 s |
| 5 | 8 s |
步骤 5：限制重试
重试策略应定义一个限制，以避免无限请求从而使服务器 API 过载。一旦达到该限制：
- 停止重试
- 向调用方暴露错误
错误代码与重试策略
本节根据 HTTP 请求的错误类型，定义了何时应触发或不应触发指数重试。
| 类别 | 使用指数退避重试 |
|---|---|
| 网络错误 | ✅ 是 |
| 408 Request Timeout | ✅ 是 |
| 429 Too Many Requests | ✅ 是 |
| 460 Client Timeout | ✅ 是 |
| 5xx Server Errors | ✅ 是 |
| 1xx Informational Responses | ❌ 否 |
| 2xx Successful responses | ❌ 否 |
| 4xx Client Errors (400, 401, 403, 404, 409, 422) | ❌ 否 |
其他未定义的错误类型应单独识别，以提高所发出请求的成功率。
给 API 使用者的最后说明
- 重试逻辑必须是确定性的且有界限的
- 服务器提供的重试提示始终优先
- 不正确的重试可能比不重试更有害
遵循这些规则可确保与服务器 API 实现可预测、安全且可扩展的集成。