說說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方認爲調用失敗

當然還要根據業務情況在具體設計，上面只是個簡單的參考。