背景
我们的团队提出了在REST API中使用状态代码206 - Partial Content的想法，以表明大型数据集上的GET请求的内容比返回的内容多，从而允许API用户进行分页。这将是我们目前在响应主体中使用的hasMore标志的替代方案。
Pro
- 使用已知的状态代码将允许API用户依赖通用HTTP语言，而不是学习我们的"专有"语言
- 声称这将是非常合适的信号是否有更多的结果
Con
- 由于所有请求都有一个
pageSize数字查询参数，因此传递206 - Partial Content可能不正确，因为响应包含pageSize查询参数请求的所有结果 206 - Partial Content通常用于字节流，而不是集合列表
问题
在哪些情况下，可以或206 - Partial Content应该用于响应restfulGET请求发送的结果集的分页？
我们的团队提出了在我们的REST API中使用状态代码206-部分内容的想法，以表明大型数据集上的GET请求具有比返回的更多的内容，从而允许API用户对进行分页
这听起来是个坏主意。
IANAHTTP状态代码注册表当前将RFC9110标识为206部分内容状态代码的权威定义。
206(部分内容)状态代码表示服务器正在成功完成范围请求。。。。
如果您还不熟悉范围请求，请参阅RFC 9110第14节。但短版本：如果传入的请求不包括Range标头，那么您就没有Range请求。
尝试重新调整206的用途，它在网络域上的通用文档传输中具有特定的意义，以表示您的定制资源模型的一些本地意义，增加了通用组件误解正在发生的事情的可能性；你希望实现的好处不太可能超过风险。
TL；DR：正常-当无聊的网络服务器会这样做时，返回一个带有200状态代码的响应。
如果您试图指示分页；状态代码是错误的工具。相反，使用诸如first/last/next/prev之类的链接关系来查看Web链接。