創建 REST API 以允許上傳大型數據集

Question

我目前正在創建一套 REST API，用於將不確定數量的信息行上傳到我們的數據庫。 這些 API 將由第三方公司團隊的開發人員使用。

信息量將從每天批量上傳約 4k 行信息開始，預計在約 4 個月內增加多達 5k 行信息。 我的問題是，設計上傳 API 的最佳方式是什么？

在我寫下一些想法之前，我一直在閱讀這里有一些需要考慮的注意事項。

• 信息的上傳和這些 API 的使用幾乎總是每天只進行一次。

• 一行信息的整體結構是這樣的，乘以 4k。

  "data": [ {"InfoID": 1, "InfoName": "HELLO", "InfoValue": 1.00, "InfoDate": "2019-01-01"}, {"InfoID": 2, "InfoName": "WORLD", "InfoValue": 2.00, "InfoDate": "2019-01-02"} ]

我在設計此類 API 時了解到的一些想法是：

• 使用頁碼信息控件限制可以在 JSON 參數上上傳的信息行數。 這意味着第三方團隊在從他們的數據庫中檢索和上傳信息時必須實施上述分頁控制。
• 上傳 CSV 文件。 這也可能實現文件上傳的分頁，以防文件太重。
• 一個 POST API 會一個一個地上傳行信息，但我相信這對於如此大的數據集來說不是最好的選擇。

任何意見、建議和想法都有助於做出設計決策。

Answer 1

我建議使用一個接受POST請求的端點。 讓請求的正文是您選擇接受它的任何格式的整批數據 - JSON、XML、CSV 等。讓客戶端指定Content-Type標頭以指示他們發送信息的格式。解析該格式以應用批量更改。 如果回復時間超過一秒左右，請立即發送202 Accepted和帶有端點的Location標頭，他們可以在其中獲得有關批處理進展情況的進度報告。

請注意，您必須決定如何處理包含一些錯誤條目的上傳 - 要么使整個批次失敗，要么接受您所能接受的。

分頁可能是矯枉過正。 根據您給出的示例，5k 個條目可能小於 1 兆字節？ 權衡這一點與客戶不得不使用分頁的煩惱。 作為客戶，我不想這樣做。

由於性能成本，要求客戶端 POST 4k 次以獲取所有數據可能不是正確的想法。 客戶端也不太可能希望自己解析數據來編寫循環。