最近我陷入了关于分页光标指定的两种思想流派:
光标仅包含其位置(如最后一个项目 ID、最后创建于...)。
因此服务器可以提供游标和查询参数的任意组合。
例如:
?queryParam=X&cursor=
,服务器响应cursor=C1
?queryParam=Y&cursor=C1
,服务器仍然能够使用新的查询参数处理此查询(即使cursor=C1
与查询参数X关联)光标包含原始查询参数。当指定游标时,其他查询参数将被忽略。
也就是说,如果查询的查询参数不兼容<->游标对,服务器可能会忽略查询参数,甚至返回错误
?queryParam=X&cursor=
,服务器响应cursor=C1
,编码为queryParam=X
?queryParam=Y&cursor=C1
,服务器从 queryParam=X
中提取 cursor=C1
并忽略请求中的 queryParam=Y
。那么对于上述两个选项,设计光标的首选方法是什么?
我上次检查时,Google API(特别是 Gmail API::list messages)使用第一种方法。
我正在开发一些 API 更新,其中包括分页。也遇到了这个。我知道这是一个老问题,但我会在这里分享我的想法。
我想说这两种方法都有各自的优点,并且可以根据您的应用程序的具体要求和限制来选择。
如果你仔细看看 Cursor Contains Only Position:
说到游标包含原始查询参数:
显然,它简化了服务器端逻辑,因为它不需要将光标映射回原始查询参数。这确保游标始终对应于同一组查询参数,从而提供一致性。
我想说的一个缺点可能会限制客户的灵活性,如果他们想在请求之间更改查询参数而不丢失光标位置。然而,如果查询参数很长,可能会导致游标尺寸变大。
根据您的要求,如果客户端在请求之间更改查询参数的灵活性很重要,那么第一种方法可能没问题。但是,如果确保游标和查询参数之间的一致性是更高的优先级,则第二种方法可能更适合。
既然您提到 Google API(Gmail API)使用第一种方法,那么值得考虑的是,他们可能会根据自己的具体用例和要求做出该决定。在决定采用哪种方法之前,必须评估您自己的应用程序的需求和限制。