我们有一个要求，我们需要在离线（非实时模式）下每天处理 10,000 笔交易。
2个选项哪个更可取
或者
我的架构师告诉我，选项 1 更可取，API 仅在批量较小时才有意义 - 因为 2 的缺点是调用 API 的人必须将有效负载分解成小块，当他们拥有所有立即提供给他们的信息。
我很想看看“2”如何成为一个可行的选择，所以任何有助于证明这一点的评论/建议都会非常有帮助。
谢谢拉胡尔
这不是一个完整的答案。但是，我想提一个支持 REST API 的原因：验证。这可以通过 API 更好地管理。将文件放入 FTP 位置后，您有责任验证文件的格式。将“坏”文件路由回其源并带有解释反弹的消息是否容易？
通过 API 调用，如果传入的表示不符合有效模式，例如 XML、json 等，那么您的服务可以响应：“400 Bad Request”http 状态代码。这保留了以有效格式向服务消费者发送数据的责任，并有助于实现更好的关注点分离。
REST API 的其他推理：
由于您的文件包含交易，因此每条记录都应该是原子的（如果这不是真的，例如文件中的记录之间存在关系，那么这些记录不应被视为“交易”）。因此，将文件分成更小的批次应该是微不足道的。
无论如何，您可以定义一个批量接受事务的服务，并以“202 Accepted”的 HTTP 状态代码进行响应。202 代码表示已收到请求并将异步处理。因此，响应还可以包含回调链接以检查单个事务的状态；或整个批次。那时，您将实施 HATEOAS（超媒体作为应用程序状态的引擎），并能够自动化整个过程并报告状态。
或者使用批处理文件，如果文件通过了前期格式验证检查，那么您仍然必须在下游单独处理每个事务。有些记录可能会加载，有些则可能不会。我的假设是仍然需要处理无法加载的记录。而且，您可能需要向用户提供成功与失败的视图。现在，这一切都可以在 REST API 之外处理。然而，为了这个目的，API 模式是简单而优雅的恕我直言。
使用批处理总是一个更好的主意。您可以使用 REST API 触发批处理。
使用批处理，您始终可以发送带有 msg "不正确文件格式" 的电子邮件，或者您也可以发送 "哪些记录已处理，哪些未处理" 。使用 Rest，您无法保留跟踪记录和交易。
正如上面评论中提到的，您可以使用 Rest API 异步触发批处理并使用 HATEOAS 发送状态响应。
SPRING BATCH + Spring REST 使用 Spring BOOT
我有同样的问题，所有答案我都找到了相同的主观答案。我想提出一些想法来比较这两个概念：
批处理解决方案需要比 REST API 更多的存储空间。您需要将结果存储在中间存储区域，并以开放格式写入。也许您可以压缩它，但您正在通过处理更改存储。
REST API 可以使用比批处理解决方案更多的网络带宽，前提是中间存储不在网络驱动器中。获取请求和查询池可能需要大量网络带宽，但可以通过 web-hooks 或 web-sockets 解决。
REST API 比批处理解决方案更容易自动恢复。REST API 响应代码可以帮助自动决定从失败中恢复。并且您减少了识别它所需的服务数量。如果网络出现故障，电子邮件可能会作为 REST API 失败。REST API 可以帮助您在这些情况下定义一个好的 API。
REST API 可以像任何其他 TCP 协议（如 FTP）一样管理大量行。但是如果发生任何故障，您将需要逻辑来管理它。这意味着 REST API 也需要启用块的协议。对于批处理服务，这个逻辑在FTP协议中，但是有他自己的逻辑，而不是你的业务逻辑。
批处理服务不需要一直保留实例（CPU、IP 地址、端口等），只需在需要时运行。您将需要一个调度程序来启动它，或者强制执行。或者如果它失败了一个人重新启动它。同样，在调度程序之外，自动化是不自然的。
批处理服务不需要开发人员进行更多的安全设置：REST API 必须注意身份验证。此外，必须考虑注入或其他攻击方法。REST API 可以使用辅助服务来防止所有这些，但这意味着更多的配置。
批处理服务易于部署。批处理服务可以在您的机器或服务器上运行，并在业务需要时运行。REST API 需要继续进行健康检查，使用部署策略来保持它，注意 DNS 配置等。检查您的公司是否为您提供所有这些服务。
如果此解决方案适用于您的公司，请检查您的公司正在做什么。现在有一个迁移到 REST API 的通用策略，但是如果您的支持团队不了解它但在批处理解决方案方面有很多经验，那么最好不要改进。