当前，我使用/users/self/media/liked方法，获取响应，读取next_max_like_id并一次又一次地请求数据。我试图传递巨大的count值，但看起来最大计数值只是30。
我需要跟踪喜欢的媒体数量的变化。有什么方法可以优化它吗？我不太了解next_max_like_id是什么意思？有什么办法可以保留它并下次以某种方式使用它？
最佳答案
users/self/media/likes的请求限制为33（默认值为20）。在分页部分中返回的next_url将使用相同的count（如果已提供）和next_max_like_id，即按时间顺序返回的最后一个结果的ID，将抓取按时间顺序排列的喜欢的项目。
据“跟踪更改”，您的意思是保持运行状态，据我所知，您无法通过端点访问喜欢的项目总数。您必须编写一个像历史一样抓取的脚本，使用分页信息向后跳，直到您看到通过复制重复的next_max_like_id达到原始效果为止（注意：返回的数据仅包括那些用户仍然有权访问）。
如果您有很多用户，则必须对原始刮板使用cron作业来交错查询，因为每小时的API调用限制为5000个。完成后，您可以在数据库中有一个last_id_liked字段，以继续进行计数维护。
我可以提供的唯一优化是，您无需计算返回的结果，而是可以计算向后跳转并乘以该计数的次数...但是您每次仍在用完API调用。