分页游标是否应该包含编码的查询参数？

Question

最近我陷入了关于分页光标指定的两种思想流派：

1. 光标仅包含其位置（如最后一个项目 ID、最后创建于...）。

   因此服务器可以提供游标和查询参数的任意组合。

   例如：

   • 第一次查询：

     ?queryParam=X&cursor=

     ，服务器响应

     cursor=C1

   • 第二个查询：

     ?queryParam=Y&cursor=C1

     ，服务器仍然能够使用新的查询参数处理此查询（即使

     cursor=C1

     与查询参数X关联）

2. 光标包含原始查询参数。当指定游标时，其他查询参数将被忽略。

   也就是说，如果查询的查询参数不兼容<->游标对，服务器可能会忽略查询参数，甚至返回错误

   • 第一个查询：

     ?queryParam=X&cursor=

     ，服务器响应

     cursor=C1

     ，编码为

     queryParam=X

   • 第二个查询：

     ?queryParam=Y&cursor=C1

     ，服务器从

     queryParam=X

     中提取

     cursor=C1

     并忽略请求中的

     queryParam=Y

     。

那么对于上述两个选项，设计光标的首选方法是什么？

我上次检查时，Google API（特别是 Gmail API::list messages）使用第一种方法。

Answer 1

我正在开发一些 API 更新，其中包括分页。也遇到了这个。我知道这是一个老问题，但我会在这里分享我的想法。

我想说这两种方法都有各自的优点，并且可以根据您的应用程序的具体要求和限制来选择。

如果你仔细看看 Cursor Contains Only Position：

• 它简化了服务器端的游标处理逻辑，还为客户端提供了在请求之间更改查询参数的灵活性，而不会影响游标本身。因此对于某些类型的数据库来说它可能会更有效。
• 另一方面，它需要服务器维护游标的状态并将其映射回原始查询参数，这可能会增加复杂性。这意味着客户端可能需要处理光标指向与当前请求不同的查询参数集的情况，这可能会导致混乱。

说到游标包含原始查询参数：

• 显然，它简化了服务器端逻辑，因为它不需要将光标映射回原始查询参数。这确保游标始终对应于同一组查询参数，从而提供一致性。

• 我想说的一个缺点可能会限制客户的灵活性，如果他们想在请求之间更改查询参数而不丢失光标位置。然而，如果查询参数很长，可能会导致游标尺寸变大。

根据您的要求，如果客户端在请求之间更改查询参数的灵活性很重要，那么第一种方法可能没问题。但是，如果确保游标和查询参数之间的一致性是更高的优先级，则第二种方法可能更适合。

既然您提到 Google API（Gmail API）使用第一种方法，那么值得考虑的是，他们可能会根据自己的具体用例和要求做出该决定。在决定采用哪种方法之前，必须评估您自己的应用程序的需求和限制。