重试后

重试时间是服务器明确指示何时可以成功重试的指令。它通常伴随 429 Too Many Requests、503 Service Unavailable 和某些重定向出现，其值可以是秒数（例如 Retry-After: 30）或 HTTP 日期。是否遵循此指令决定了客户端是能够恢复服务还是会延长等待服务中断的时间。

工作原理

客户端解析该值——两种形式都有效且都存在——并安排不早于此的重试时间。如果缺少请求头，客户端将回退到自身的退避策略。优秀的客户端还会限制等待时间，因此配置错误的服务器不会让客户端长时间处于等待状态。

误解

使用固定一秒休眠的重试循环来"handling 429" 。每个执行此操作的客户端都会在窗口打开的瞬间立即再次向服务器发送请求。如果存在 `Retry-After` 参数，它已经提供了正确的重试次数；如果没有，则使用带抖动的退避机制。

点击这里试试

GET /coffee/v1/rush-hour允许每十秒钟发出三个请求，并对第四个请求返回 429 和 Retry-After；GET /protocol/v1/maintenance对每个请求返回 503 和 Retry-After: 30。

相关内容

• Testing rate limiting and Retry-After
• HTTP 429 Too Many Requests

资料来源

• HTTP semantics — RFC 9110
• HTTP caching — RFC 9111

其他术语

• ETag — 用于表示形式的不透明版本标识符，用于避免重新发送该表示形式并检测冲突的写入。
• 安全且等效的方法 — HTTP 方法的两个独立属性决定了客户端可以重试哪些方法。
• PUT 与 PATCH — PUT 参数将资源替换为您发送的表示形式；PATCH 参数将一组更改应用到该资源。
• 指数退避 — 一种重试策略，其中每次等待时间都比上一次更长，并添加随机性，以防止客户端同步重试。
• 请求超时 — 客户端在放弃请求之前等待响应的最长时间。

阅读英文版

所有术语 · 测试技巧 · 全部 39 个模拟 REST API

最后更新时间 2026年10月16日