创建 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 次以获取所有数据可能不是正确的想法。 客户端也不太可能希望自己解析数据来编写循环。