OData 客户端在构造请求时不得使用系统查询选项 $skiptoken。
$skiptoken 是一个服务器端实现,在许多情况下,您甚至无法猜测正确的值可能是什么。 TripPin 服务是一个非常简单的演示 API,它使用 8 的页面大小来说明服务器端分页的行为,考虑到整个数据集的小尺寸 (20),这是一个不错的任意数字,将导致多个页面最后一页只有部分已满。这足以测试服务器端支持数据接口的基本合规性。
服务器端分页旨在鼓励搜索驱动用户优先制定更精确的搜索标准的界面浏览逐页浏览页面。Virtual Scrolling 是一种利用服务器端分页的常见用户界面范例。不同的语言和运行时有不同的实现,但基本上用户可以滚动数据列表或网格,当他们到达底部时,可能会有一个“加载更多”记录的链接(在幕后,这将加载来自下一个链接)。有时此链接不会显示,当用户接近或到达列表末尾时会自动加载数据。
您仍然可以使用传统的客户端使用$top 和$skip 查询参数进行分页,但是一些服务实现服务器端分页仍会将结果限制为该服务器内部逻辑定义的固定行数。如果您正在实施客户端分页,那么您可能仍需要使用下一个链接检索每个结果的所有结果客户端结果页面。
让我们通过首先获取第 2 页来比较客户端页面大小为 5:
获取:~/TripPinServiceRW/People?$skip=5&$top=5
{
"@odata.context": "http://services.odata.org/V4/(S(ysqt4lcalbsipb1qkoc04ryb))/TripPinServiceRW/$metadata#People",
"value": [
... 5 records ...
]
}
请注意,响应中没有@odata.nextLink 属性,这是因为请求的项目数没有超过服务器页面大小逻辑。所以让我们尝试页面大小为 9。这一次,要检索页面的所有记录,我们需要进行多次查询。
这里的一般指导是递归地为每个下一个链接响应中的 url,如果它们包含下一个链接
获取:~/TripPinServiceRW/People?$skip=9&$top=9
{
"@odata.context": "http://services.odata.org/V4/(S(ysqt4lcalbsipb1qkoc04ryb))/TripPinServiceRW/$metadata#People",
"@odata.nextLink": "https://services.odata.org/V4/(S(ysqt4lcalbsipb1qkoc04ryb))/TripPinServiceRW/People?%24skip=9&%24top=9&%24skiptoken=8",
"value": [
... 8 records ...
]
}
获取:~/TripPinServiceRW/People?%24skip=9&%24top=9&%24skiptoken=8
{
"@odata.context": "http://services.odata.org/V4/(S(ysqt4lcalbsipb1qkoc04ryb))/TripPinServiceRW/$metadata#People",
"value": [
... 1 record ...
]
}
当您实现自己的符合 OData-v4 的 API 时,了解这一点很重要怪癖并在您的 API 文档中具体记录您的政策或惯例是什么服务器端分页以及启用它的集合。
在我自己的实现中,我经常会禁用如果请求包含服务器端分页客户寻呼令牌$top($top 的值是 <= 200)但是
从一个客户端如果你看到一个执行下一个链接响应中的属性并且您没有收到预期的记录数,那么您应该查询后续服务器页面如果您无法实施虚拟卷轴启用用户体验。
笔记:通常,当我们讨论 OData v4 服务中的分页时,示例将包括使用 $count 查询选项。
[11.2.9 请求集合中的项目数]:成功时,响应正文必须包含在应用任何$filter 或$search 系统查询选项后与请求匹配的项目的确切计数...
返回的计数不得受$top、$skip、$orderby 或$expand 的影响。
TripPin 服务不符合规范中的这个特定(和许多其他)子句,所以我没有在这个解释中使用那个查询选项。