如何确保分页的REST API中的数据完整性？
我正在使用REST API。 API返回的资源预计将是来自数据库的巨大数据（数据库中的数千万行）。将数据写入HTTP响应时，为了避免巨大的内存消耗，分页是必须的。如何确保分页的REST API中的数据完整性？
如何在客户端请求之间在数据库中删除/添加行时确保数据完整性？
例如：
page 1: [ John, Mary, Harry, David, Joe ]
page 2: [ Mike, Don, Alex ]
请求页面1和本地存储它在（文件/存储器）客户端之后，要求第2页之前，所述数据被改变为：
page 1: [ John, Mary, Harry, David, **Mike** ]
page 2: [ Don, Alex, **Terry** ]
一个真正的RESTful（因此服务器端的无状态）的答案是：
- 问前五个记录（最后一个是“乔”），
- 然后询问五个记录优越[1]给“乔”，
- 等。
通过此策略，您将在页面＃2中获得“Mike”和“Terry”。
[1]他们必须有一个排序顺序（按字母顺序排列或其他）。
对此的一个解决方案是返回表示查询结果集的“临时”资源，然后允许客户端通过使用GET进行分页。
例如：
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）允许服务器获得它被占用的内存。
另一种方法是每次重新发出查询，然后分页到结果集中查找要返回的正确数据块。这是无状态的，不需要像早先的想法那样的驱逐策略，但它确实意味着每次都会重新运行查询。它的好处是每个分页的结果都尽可能准确。
你对第一种解决方案的缺点是正确的。结果集有时会随时更改，并且时序不在我的API完全控制之下，因此不应该有方法来确定何时是在“快照”视图中使结果集无效的最佳时机。因此，在这种情况下重新运行查询应该更合适。 – seriousmegalor 2013-03-08 15:40:32
“上级”在这里是一个令人困惑的词......你需要能够在记录“乔”后询问下一页（N项）......你会得到一个错误，指出“乔”已不在所以引用将是无效的，然后客户端会再次请求第一页。 – Peter 2015-05-05 01:01:07
@Peter不，“Joe”在这里是纯字符串值，而不是实际的项目。所以，乔的物品不再存在的事实对它没有影响。这个策略是CouchDB社区中一个众所周知且经过现场验证的“配方”。 – 2015-05-05 05:21:53