Twitter GET statuses/user_timeline 返回的记录太少

Twitter GET statuses/user_timeline returning too few records

在我们网站的新闻页面上,我们使用 Twitter 的 GET statuses/user_timeline API 端点为我们显示的 8 个新闻报道的每个 Ajax 页面引入 4 条推文,使 4结果网格中的 3 个链接行。这对于前 8 页效果很好(就推文而言,这让我们回到了一个多月后)。但是当我到达 API 调用以获取第 9 页的 36 条推文和第 10 页的 40 条推文时,它只有 returns 35 和 38 条推文。

我认为这可能归因于 David Yell mentioned in his answer here 这个问题,搜索 API 而不是 return 它认为质量低下的推文。如果我转到我们公司 Twitter 帐户的时间线,我可以看到被省略的特定推文 — 我认为它们不一定是垃圾邮件或低质量的,一个有 47 次互动(21 次转发,22 次点赞和 4 次回复) 和另一个有 12 个这样的交互,所以它们不像是刚刚发出的推文回响到虚空,但可以肯定的是,也许算法不同意或其他什么。

API 调用在整个过程中实际上是相同的;如果我从我的(定制 C#)代码中记录 API 调用 URL 以及 returned JSON 中的推文数量,它就像 [=16] 一样简单=] return只发了 35 条推文,…/statuses/user_timeline.json?count=40&… return只发了 38 条推文,所以 API 调用本身似乎没有任何问题,尤其是考虑到之前的 8 个电话都有正确数量的推文(所以 ?count=32… 在 JSON 响应中有 32 条推文等等。)我知道自从 QA 分析师在本周早些时候发现这一点以来我们已经发布了更多推文结果网格中“缺失”条目的形状一直保持一致,但直到今天我们的调试还不够深入,无法确认缺失的推文是否相同。

有没有人有过说服API到return那些“失踪”的推文的经验?还是我必须想出如何记录并传入修改后的偏移量,以确保我在结果网格中仍然得到 4×3 的偶数页,没有间隙? (或者什么的。)

有些应用程序使用 count 来获取多个条目,如果可用数量低于此数量,则它会填充 null 或 return 一个缺少目标数量的数组。

在这种情况下,Twitter 详细说明了 count 的意思“最好将其视为对 return 的推文数量的限制,因为暂停或删除的内容在应用计数后会被删除。 ".

Twitter 还指出,即使未提供 include_rts,该计数也包括转推。

https://developer.twitter.com/en/docs/twitter-api/v1/tweets/timelines/api-reference/get-statuses-user_timeline