GitHub API:如何改善对活动事件的非常有效的轮询？

Question

GitHub的API提供了活动事件的特征users,orgs和repos.API支持分页最多10页,总共300 页,每页events30 events页.使用ETAG标头实现速率限制.我正在尝试轮询此API以获取最新活动.然而,由于Github所提供的设计,该方案非常低效.可以说,我就请求page-1通过

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

我将获得ETAG此页面的条目.现在我移动到下一个page-2并做

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

并将获得ETAG第2页.同样,我可以从所有10个支持的页面中提取事件.

现在让我们说我的orgs Github帐户上执行了一些活动.让我们假设只发生了一个新事件.在这种情况下,当我使用它poll的API 将返回已更改的页面,其中包含新的.同样在其前面也将发送改变页.然而,这种变化是之前最后一次事件并且现在已经移至顶部的事件.所有页面都会发生这种"转移到下一个".没有办法找出发生的新事件的数量.唯一的解决方案是继续轮询以获取最新信息.然而,这种方法有一个严重的缺陷解释如下:page-1ETAGeventpollingpage-2ETAGpage-2page-1page-2page-1events

当events我的poll轮次之间的新数量大于30(一页上的最大项目)时,情况会变得更糟.在这种情况下,最新的30个事件之前的事件将page-2直接滑到.如果我只是poll在page-1我身上会失去这些滑倒的事件page-2.我想到的唯一解决方案是保留整个事件的缓存,然后扫描所有页面.然而,这是一种非常有效且不可取的方式,并且杀死事件通知API的目的.

我希望有些github-dev可以回答这个问题

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步