在我之前的帖子中，我解释了一种 API 设计，它让用户可以选择执行立即操作、使用默认触发、忘记或使用显式批量机制。这个想法是大多数操作都是小的，实际通过网络的成本将主导整个操作的成本。在这种情况下，我们希望为用户提供选择“我想知道操作完成”或“我只想尝试最好的，如果有失败我也没关系”模式的选项。
伊莱 问 ：
试图理解为什么这不仅仅是一个脚本案例。在您的示例中，您遍历 CSV 并建议每个部分进行增量调用，该部分在用户控制之外进行批处理和提交。为什么不在服务器上定义一个 JavaScript，它接受通过网络发送的部分数组（“一批”）并在服务器上迭代它？这样用户就可以对批次进行细粒度的控制。我猜答案与您的分布式计数器架构有关......
如果我对 Eli 的理解正确的话，我的想法是我们将公开这样一个 API：
Increment(“users/1/visits”, 1);
并提供一个端点，用户可以在其中发布将调用它的 JavaScript 代码。这个想法是用户将能够决定调用一次，或者一次性发送一整批更新。
这当然是一种选择，但在我深思熟虑后认为，这是一个非常糟糕的选择。它与分布式架构无关，它与我们给用户带来的负担有关。 “一路走到服务器并确认操作”与“让我们做批量插入之类的事情”的实际语义非常简单。他们每个人都有一个非常明确的行为。
但是当你想对每个页面视图执行一个操作时会发生什么？从您的代码的角度来看，您正在执行单个操作（增加特定实体的计数器）。从整个系统的角度来看，您正在生成大量单独的请求，这些请求作为单个批量请求会好得多。
当然，拥有脚本端点可以让用户选择这样做，但是他们需要处理：
- 错误恢复
- 多线程
- 批量大小/时间冲洗
- 故障转移
还有很多我可能忘记了。通过为用户提供关于速度与安全性的明智选择的选项，我们避免将实际实施的责任推给他们。