如何通过轮询等方式处理HTTP协议下的延迟响应问题

1. 告知客户端等待及指定重试时间的方法 #

标准实现是在服务端的首次响应头中携带Retry-After字段，该字段支持两种取值格式：

• 非负整数：代表客户端需要等待的秒数，从响应生成时间开始计算
• 符合HTTP规范的日期字符串：代表客户端可以发起重试的具体时间点
  如果需要传递更多业务相关的状态信息，可以在响应体中新增自定义字段，比如任务处理进度、唯一任务ID等，方便客户端做后续状态校验

2. 适配Retry-After头的HTTP状态码 #

RFC 7231明确规定了两种可搭配Retry-After使用的状态码，可根据场景选择：

• 202 Accepted：完全匹配当前场景，语义为「请求已被服务端接收，尚未处理完成」，RFC 7231第6.3.3节明确允许202响应携带Retry-After头，用于告知客户端后续查询处理结果的时间，不会让客户端误判为服务不可用。
• 503 Service Unavailable：语义为「服务端当前无法处理请求」，通常用于过载、停机维护的场景，如果需要兼容部分对202搭配Retry-After支持不好的旧客户端，可以使用503，但需要在响应体中明确说明当前是请求处理中，避免客户端误判服务状态。

3. 重试/轮询的实现方式 #

如果服务端没有返回额外的任务标识，等待Retry-After指定的时间后直接重发原始请求即可，这是通用的标准化实现。
性能更优的轮询方案需要服务端配合做少量改造：

• 首次返回202响应时，在响应体中返回唯一的任务ID，同时提供专用的任务状态查询接口
• 客户端后续轮询时直接调用状态查询接口，不需要重复提交原始业务请求，降低服务端重复处理的资源开销
• 任务处理完成后，状态查询接口可以直接返回处理结果，也可以返回303 See Other状态码搭配Location头，指向最终结果的获取地址
  轮询频率需要严格遵循Retry-After的要求，避免频繁请求触发服务端限流，如果后续响应中返回了新的Retry-After值，需要按最新值调整等待时间

内容的提问来源于stack exchange，提问作者dvo