GitHub API:如何提高对活动事件的高效轮询

Question

GitHub API提供了users、orgs和repos的活动事件功能。API支持最多10页的分页，总共300个events，每页30个events。使用ETAG报头来实现速率限制。我正在尝试轮询此API以获取最新的活动。然而，由于上述Github支持的设计，该方案非常有效。假设我通过在page-1上提出请求

https://api.github.com/users/me/events/orgs/my-org?page=1

并且我将获得该页面的CCD_ 8条目。现在我转到下一个page-2并进行

https://api.github.com/users/me/events/orgs/my-org?page=2

并将获得该第2页的CCD_ 10。同样，我可以从所有10个支持的页面中提取事件。

现在让我们假设一些活动是在我的组织Github帐户上执行的。假设只发生了1个新事件。在这种情况下，当poll为page-1和ETAG的API时，它将返回包含新event的已更改页面。类似地，page-2上的polling及其前一个ETAG也将发送已更改的页面。然而，page-2中的这一变化是之前page-1的最后一个事件，现在已移动到page-2的顶部。所有页面都将发生这种"转移到下一页"的情况。没有办法找出发生的新事件的数量。唯一的解决方案是在page-1上继续轮询以获得最新的events。然而，这种方法有一个严重的缺陷，解释如下：

当我的poll轮之间的新events的数量大于30（一页上的最大项目数）时，情况会变得更糟。在这种情况下，最新的30个事件之前的事件将直接滑到page-2。如果我在page-1上仅poll，我将释放这些滑到page-2的事件。我想到的唯一解决方案是缓存整个事件，然后扫描所有页面。然而，这是一种非常高效和不可重复的方法，并扼杀了事件通知API的目的。

我希望一些github开发人员能够回答这个

Answer 1

由于每个事件都有一个ID，并且事件在响应中排序，因此您只需要记住上一个响应中第一个事件的ID（而不是所有事件）。

所以，我会这样做：

初始提取：

1. 获取所有事件页面（从1到10的页面）
2. 存储第一页的ETAG
3. 将第一个事件的ID存储在第一个页面中

后续回迁：

1. 使用存储的ETAG有条件地获取事件的第一页
2. 如果接收到304未修改的响应，则没有新的事件，因此终止
3. 如果收到一个200 OK的响应，那么我们就有了新的事件。按顺序从1到10提取页面，直到第一个页面包含ID等于存储ID的事件。所有新提取的事件直到该事件都是新事件，应该进行处理。因此，新事件的数量是通过获取所有事件直到您以前看到的事件而逐渐发现的。而且你只获取你必须获取的页面，而不是更多
4. 存储第一页的ETAG
5. 将第一个事件的ID存储在第一个页面中
6. 等待一段时间，然后转到步骤1