如何确保分页RESTAPI中的数据完整性？

我目前正在开发RESTAPI。API返回的资源预计是来自数据库的巨大数据（以DB表示的数千万行）。在将数据写入HTTP响应时，必须进行分页，以避免巨大的内存消耗

在客户端请求之间的数据库中删除/添加行时，如何确保数据完整性

例如：

page 1: [ John, Mary, Harry, David, Joe ]
page 2: [ Mike, Don, Alex ]

GET /big-query/all-users
Returns: /query-results/12345 

GET /query-results/12345?page=1
Returns: users 1-20

GET /query-results/12345?page=2
Returns: users 21-40

在客户端请求第1页并将其本地存储在（文件/内存）中之后，在请求第2页之前，数据更改为：

page 1: [ John, Mary, Harry, David, **Mike** ]
page 2: [ Don, Alex, **Terry** ]

---

一种解决方案是返回一个表示查询结果集的“临时”资源，然后允许客户端使用GET对该资源进行分页

例如：

page 1: [ John, Mary, Harry, David, Joe ]
page 2: [ Mike, Don, Alex ]

GET /big-query/all-users
Returns: /query-results/12345 

GET /query-results/12345?page=1
Returns: users 1-20

GET /query-results/12345?page=2
Returns: users 21-40

此解决方案的一个明显问题是，对实际用户的更改不会反映在查询结果集中，因此您应该在API文档中明确这一点。此外，最好在合理的时间后“过期”结果集，以（a）防止它过时，以及（b）允许服务器获取它所持有的内存

另一种方法是每次重新发出查询，然后对结果集进行分页，以找到要返回的正确数据块。这是无状态的，不需要像前面的想法那样的逐出策略，但它确实意味着每次都将重新运行查询。好处在于，每次分页的结果都会尽可能准确。

真正的RESTful（因此服务器端无状态）答案是：

• 询问前五张记录（最后一张是“Joe”）
• 然后询问“乔”的五项记录上级[1]
• 等等

使用此策略，您将在第2页看到“Mike”和“Terry”

---

[1] 它们必须有一个排序顺序（按字母顺序或其他顺序）。

第一种解决方案的缺点是正确的。结果集需要不时更改，并且计时不在我的API的完全控制之下，因此不应该有办法确定何时是在“快照”视图中使结果集无效的最佳计时。因此，在这种情况下，重新运行查询应该更合适。“superior”在这里是一个令人困惑的词。。。您需要能够要求在记录“Joe”之后的下一页（N项）。。。您将收到一个错误，说明“Joe”已不存在，因此引用将无效，客户端将再次请求第一页。@Peter no，“Joe”在这里是纯字符串值，而不是实际项。因此，乔的物品不存在的事实对它没有影响。这个策略在CouchDB社区中是一个众所周知且经过现场验证的“配方”。我不明白，如果在请求第一页后添加Garry，这会有什么帮助？