带有批处理请求的 RESTful API

Posted 2023-03-31

【中文标题】带有批处理请求的 RESTful API

【英文标题】：RESTful API with Batch Requests

【发布时间】：2014-02-04 16:19:13

【问题描述】：

我们的单页应用和移动应用使用的不是那么 RESTful API。

它不是那么 RESTfu，因为在过去，URI 会返回对特定页面有用的任何内容。这导致了大量端点，其中许多具有非常相似的响应。

在数据方面，我们拥有数十个相关资源。在某些情况下，我们希望返回这些相关资源，或者其中一些，而在其他情况下我们不希望。有些返回很慢，因此我们只希望在特定情况下使用它们。

我们遇到的问题是将数据拆分为有意义的 URI，而不需要另一个请求来获取每个相关资源。

因此，我们考虑了一个 /batch 端点，其中在主体中包含多个请求的 POST 请求可以在服务器上并行执行这些请求。赞这个https://developers.facebook.com/docs/graph-api/making-multiple-requests

这样我们可以将数据拆分为有意义的 URI，而不必为每个页面发出 20 个 API 请求。

这是处理相关资源的可接受方式吗？还是为我们可能想要的每个响应都有一个 URI 会更好？

【参考方案1】：

HTTP/2 允许您在单个连接上多路复用请求，从而解决这个问题。

同时，我建议您当前的解决方案不要违反任何 REST 约束。但是，创建一批请求会破坏资源识别约束，这将对表示的可缓存性产生重大影响。

【参考方案2】：

批处理很好——不要让 RESTful 设计模式引导您走向糟糕的性能。

您的批处理解决方案很可能可以设计为可以单独调用每个可以批处理的部分。如果是这样，也可以直接为每个端点创建 RESTful 端点，对于那些希望以多次往返为代价的人来说。

您还可以使用查询参数来选择不同的、打包的资源返回。例如，对于用户，您可以使用如下内容：

GET /v1/users/1?related=none,all,basic

您也可以使用字段选择器：

GET /v1/users/1?data=addresses,history

【讨论】：

批处理 GET 请求会破坏缓存，这是良好 Web 性能的基石之一。

缓存的优势始于对资源的第二次请求。如果获得缓存优势的机会很小或不存在，那么批处理 GET 请求可能非常有意义。即使被缓存，每个请求都会产生一些开销。