TikTok 的公共网络端点并不总是返回应用程序请求的页面大小。一个路由可能返回一个较小的原生窗口，另一个路由即使存在更多数据也可能未填满页面，而游标所代表的含义可能比简单的数字偏移量更为复杂。
这很快就会成为一个生产环境中的问题：
-
count（计数）可能与返回的记录数量不一致。 - 应用程序可能通过自行计算游标而跳过某些项目。
- 连续的上游窗口可能包含相同的项目。
- 响应可能声称存在更多数据，但未向客户端提供安全的续传值。
- 缺失的布尔值可能被静默转换为
false，从而改变其含义。
在构建公共 TikTok 元数据 API 时，我将分页视为一种应用程序契约，而不是对上游请求的简单透传。
首先定义响应契约
每个列表响应都遵循以下不变量：
page.count === page.data.length;
page.data.length <= requestedCount;
响应还包含：
{
"request_id": "correlation-id",
"data": [],
"count": 0,
"cursor": null,
"has_more": false
}
重要的规则如下：
-
count（计数）描述的是实际返回的记录数，而非请求的页面大小。 -
has_more=true表示返回的cursor（游标）可用于下一次请求。 - 客户端原样复制游标。
- 最后一页包含的项目数可能少于请求的数量。
- 服务绝不会用重复记录填充页面。
数字游标和不透明游标是不同的
评论和评论回复暴露了 TikTok 的数字续传游标。它看起来可能像是一个偏移量，但最安全的做法是客户端仍将其视为服务器拥有的状态。
创作者视频、音乐视频、标签 feed（信息流）、搜索以及“探索/热门”结果使用带签名的不透明游标。该不透明值可以保留：
- 上游续传状态
- 填满上一个客户端页面后剩余的记录
- 在合并原生窗口时已发出的 ID
- 游标所属的资源或搜索查询
为某个创作者或关键词返回的游标不能复用于其他创作者或关键词。
构建一个可重用的客户端
这个 Node.js 18+ 示例调用 API
免责声明：本文内容来自互联网，该文观点不代表本站观点。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌抄袭侵权/违法违规的内容，请到页面底部单击反馈，一经查实，本站将立刻删除。
