分页REST API：如何选择返回的数据量？

Question

我知道，从当今大多数REST API中，必须对Web调用响应进行分页。 但是，我在网络上看不到如何选择API调用返回的批处理的理想大小的任何见解：应该是10、100、1000。简而言之：我们应该基于哪些因素来反映API响应的大小？

有人说它应该基于UI显示的元素数量。我不同意这一点，因为并非所有API都直接与UI链接，并且在任何情况下，现代REST API都允许使用可配置的参数选择输出批处理中的项数，其数量最多为一定数量。

那么，我们如何为“ HTTP请求返回的最大元素数”定义值？ 应该基于有效载荷大小吗？ API的内部架构？是否应基于绩效评估？

对此有何见解？我并不是真正在寻找一个明确的数字，而是更多可以帮助找到答案的技术。对我而言，最好的方法是遵循一些成功的API。但是，我找不到任何东西。

Answer 1

我一般的做法是：

1. 尝试避免分页
2. 通过使用next和previous链接，而不是使用?page=属性，使REST客户端可以抵抗分页更改。 REST客户端通过链接的外观严格知道另一个页面是可用的。

我不使用严格的规则或度量来确定何时需要分页。分页通常很痛苦，所以我的第一种方法是尝试找出哪些需求驱动了对分页的需求，以及该需求是否可以消除。

一旦我确定不可能以另一种方式删除此要求，我将页面的截断尺寸设置为合理，以消除客户端可能需要执行其他请求的可能性。

Answer 2

如果它是封闭的API（仅由您控制的客户端使用），请选择UI所需的任何内容。改变是微不足道的。如果客户可以从多个选项中进行选择，则可以包含一个pageSize参数。或者更好。.

如果它是开放的API（不受您控制的客户端使用），则让客户端控制所需的分页大小。而不支持pageNumber参数，而是支持offset和limit。偏移量是开始返回记录之前要跳过的记录数，而限制是要返回的最大记录数。如果客户端对请求的执行方式不满意，则可以调整参数以适合他们的需求。 API的任何上限都应由您的服务可以处理的驱动。试图找出使所有客户满意而又不会让客户感到悲伤的Magic Maximum Page Size是不可能的，也不是您想要的。

另外，请注意，这与ReST无关，后者在分页时保持沉默。

Answer 3

我通常用手进行粗略的性能测量。我想要尽可能少的请求，但不想冒险超时。