API分页最佳实践

我经过深思熟虑，最终找到了下面所描述的解决方案。虽然这是一个相当复杂的步骤，但如果你采取了这一步，你将得到你真正想要的结果，即未来请求的确定性结果。
你提到删除项目仅仅是冰山一角。如果在请求之间有人更改了物品颜色，那么按照“颜色=蓝色”的过滤器可靠地分页获取所有物品是不可能实现的...除非我们实施“修订历史”。
我已经实施了这个功能，而且它其实比我预期的要简单。我做的如下：

• 我创建了一个名为“changelogs”的表，并带有自动增量ID列
• 我的实体有一个“id”字段，但这不是主键
• 实体有一个“changeId”字段，既是主键，也是外键引用“changelogs”。
• 每当用户创建、更新或删除记录时，系统都会在“changelogs”中插入新的记录，抓取id并将其分配给实体的“新”版本，然后将其插入到数据库中。
• 我的查询选择最大的changeId（按id分组），并进行自连接以获取所有记录的最新版本。
• 筛选器应用于最新的记录
• 状态字段跟踪项目是否被删除
• 最大的changeId返回给客户端，并在后续请求中添加一个查询参数
• 因为只有新的更改才会创建，每个changeId都代表了更改创建时基础数据的唯一快照。
• 这意味着你可以永久缓存具有changeId参数的请求结果。这些结果永远不会过期，因为它们永远不会改变。
• 这也开启了令人兴奋的功能，如回滚/还原，同步客户端缓存等。任何从更改历史中受益的功能。

参考API分页设计，我们可以通过游标来设计分页API。

他们有一个叫做游标的概念——它是一行的指针。因此，你可以对数据库说：“在那个之后给我返回100行”。由于有一个索引字段，你很可能能够确定行，所以这对于数据库来说更容易实现。突然间，你不需要获取和跳过那些行，而是直接跳过它们。 以下是一个例子：

  GET /api/products
  {"items": [...100 products],
   "cursor": "qWe"}

API返回一个（不透明的）字符串，您可以使用它来检索下一页：

GET /api/products?cursor=qWe
{"items": [...100 products],
 "cursor": "qWr"}

实现上有很多选择。一般来说，你会有一些排序标准，比如产品ID。在这种情况下，您将使用一些可逆算法（例如hashids）对产品ID进行编码。并且在接收到带有光标的请求后，您会对其进行解码并生成类似于WHERE id>：cursor LIMIT 100的查询。
优点：

• 可以通过cursor提高数据库的查询性能
• 在查询时处理新内容插入到数据库中的情况

缺点：

• 无法为无状态API生成previous page链接

我最终来到这里，是因为我想知道MS Exchange Online PowerShell命令（如Get-QuarantineMessage）返回的数据有多少是没有返回的。根据所有的阅读，我得出的结论是，消费者永远不能相信分页服务提供商会返回所有的结果。开发人员主观性、技能差距、误解等问题太多了。分页只有一个好处，那就是性能保护，但代价是无法保证数据的完整性。
但这不是什么大问题，只是好知道而已。