5

GitHub API为users、orgs和提供活动事件功能repos。API 支持最多 10 个页面的分页，总共 300个页面，每页events30events个页面。速率限制是使用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 帐户上执行了一些活动。让我们假设只发生了 1 个新事件。在这种情况下，当我poll使用 API时page-1，ETAG它将返回已更改的页面，其中event包含新的页面。与它的previous类似polling，也会发送改变的页面。然而，这个变化是之前的最后一个事件，现在已经移到了顶部。这种“转移到下一个”将发生在所有页面上。没有办法找出发生的新事件的数量。唯一的解决方案是继续轮询以获取最新的。然而，这种方法有一个严重的缺陷，解释如下：page-2ETAGpage-2page-1page-2page-1events

events当我的poll回合之间的新数量大于 30（一页上的最大项目数）时，情况会变得更糟。在这种情况下，最新的30个新事件之前的事件将page-2直接滑到。如果我只poll在page-1我将失去这些滑落到的事件page-2。我想到的唯一解决方案是保留整个事件的缓存，然后扫描所有页面。然而，这是一种非常低效且不可取的方法，并且会破坏事件通知 API 的目的。

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

4

1 回答 1

7

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

所以，我会这样做的方式是：

初始获取：

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

后续提取：

  1. 使用存储的 ETAG 有条件地获取事件的第一页
  2. 如果收到 304 Not modified 响应，则没有新事件，因此终止
  3. 如果收到 200 OK 响应，那么我们有新事件。从 1 到 10 依次获取页面，直到包含 ID 等于存储的 ID 的事件的第一页。直到该事件之前的所有新获取的事件都是新事件并且应该被处理。因此，作为获取所有事件的结果，新事件的数量会逐渐发现，直到您之前看到的事件。而且您只获取您必须获取的页面，仅此而已。
  4. 存储第一页的ETAG
  5. 将第一个事件的 ID 存储在第一页中
  6. 等待一段时间，然后转到步骤 1
于 2013-06-25T15:33:20.890 回答