说说HTTP 202状态码的场景

最近线上有对接其他系统的HTTP请求，总是取不到数据，导致数据偶尔丢几次。这是个交接过来的系统，之前也没对过API，后来拿到API以及测试之后，才发现是202状态码的异步任务导致的。

概念

• rfc2616
• MDN HTTP 202

200 OK

200 OK 表明请求已经成功. 默认情况下状态码为200的响应可以被缓存。
不同请求方式对于请求成功的意义如下:
GET: 已经取得资源，并将资源添加到响应的消息体中。
HEAD: 响应的消息体为头部信息。
POST: 响应的消息体中包含此次请求的结果。
TRACE: 响应的消息体中包含服务器接收到的请求信息。
PUT 和 DELETE 的请求成功通常并不是响应200 OK的状态码而是 204 No Content 表示无内容(或者 201 Created表示一个资源首次被创建成功)。

202 Accepted

202 Accepted 表示服务器端已经收到请求消息，但是尚未进行处理。但是对于请求的处理确实无保证的，即稍后无法通过 HTTP 协议给客户端发送一个异步请求来告知其请求的处理结果。这个状态码被设计用来将请求交由另外一个进程或者服务器来进行处理，或者是对请求进行批处理的情形

202状态码适合异步任务或者说需要处理时间比较长的请求，避免HTTP连接一直占用，超时这些情况。常见的就是使用MQ异步处理批任务，客户端定时轮训结果。

流程

系统中对接的接口，大部分都是同步的请求，也就说发送一个HTTP请求，正常时候就是返回200状态码和预期的结果

client ---------> server 
      <---200---

这个接口的模式client第一次请求得到一个TaskID + 202状态码，之后需要client根据TaskID轮训，直到得到结果

client -----post + 参数--------> server 
      <----202 + TaskID -------


client -----get + TaskID -----> server 
       
      1| <- 202 + status:runing--
      2| <- 200 + status:done + 返回内容
      3| <- 404 or 500
      
如果是202还需要继续轮训

举个例子

一个接口为 /api/v1/month_report, 功能是返回某个月的报表数据，处理耗时一般30～60秒，可以这样设计

• client 发送POST /api/v1/month_report 参数为 {'month':'2019-02'}, 服务端接受参数并且返回状态码 202，body为 {'taskid': 'cxxxx0001'}, 服务端下发一个任务到MQ或者其他异步处理的方式，同时记录 task cxxxx0001 的状态为 running

• 10秒之后 client 发送 GET /api/v1/month_report/cxxxx0001 获取任务结果，此时服务端可能有几种情况

  • 任务成功，返回 200 , 内容为 {"status": "done", "details": {....}}
  • 任务还在执行中，返回 202， 内容为 {"status": "running"}
  • 任务失败，返回 200（或者404）, 内容为 {"status": "failure"}

• 如果client获取到是202状态，再过20s重试一次，比如说2分钟之后仍然没有成功，可以继续轮训，或者根据需要定义timeout, client方认为调用失败

当然还要根据业务情况在具体设计，上面只是个简单的参考。