Github API带分页的条件请求

Question

上下文：假设我们希望按给定用户定期（每天，每小时或几分钟）检索已加星标存储库的整个列表。

有这样做至少2种方法：

1）执行GET来https://api.github.com/users/evereq/starred并使用网址使用rel =“下一步”，在“链接”响应头以获得下一个页面URL（我们应该做的，直到我们没有得到任何“下一页”的回应，意味着我们到了最后）。似乎这是推荐的方法（由Github）。

2）使用GET到https://api.github.com/users/evereq/starred?page=XXX迭代'page'参数（从1到无限），直到得到0个响应结果。你得到0结果，你完成（不推荐，因为例如，而不是页码Github可以移动到“散列”值。Github已经做了一些API操作）。

现在，假设我们要确保我们使用条件请求（请参阅http://developer.github.com/v3/#conditional-requests）来保存我们的API使用限制（以及流量，世界树木等）。

因此，我们在我们的请求标题中添加例如'If-None-Match'，并检查响应状态是否为304（未修改）。如果是这样，这意味着我们上次请求没有任何变化。这工作正常。

但是，我们在上面1）和2）中所涉及的问题与我们如何检测何时停止的方式在您使用条件请求时不再有效！

I.e.通过方法1），当您使用条件请求时，您根本没有获得链接响应头。 因此，您需要执行一个请求，使页面大于您已经拥有ETag的页面，并且看到它返回0个结果并且您知道您已完成。这样，你基本上“浪费”了一个对Github API的请求（因为它错过了Conditional Requests Headers）。

与方法2）相同，在状态304的每个请求中基本上都有0个响应...因此，要知道您已完成，您需要至少创建一个返回0结果的附加请求。

所以问题是：当我们通过Github API不发送链接响应标题（至少在使用ETag查询结果状态为304的情况下）时，我们如何知道什么时候停止分页？这是Github API实现中的错误还是我错过了一些东西？

我们不知道最大页码，所以得到何时停止我们应该再执行一个“浪费”请求，并检查我们是否得到0个结果！

我也无法找到如何查询Github的星号存储库的总数（所以我可以计算我应该在建议中迭代多少页），与响应一样，不包括“X-Total-Count”所以我知道何时停止使用简单的数学计算页数。

任何想法如何保存一个（'结束'）请求，仍然使用条件请求？

如果你每天做一个请求，可以接受这样的浪费，但是如果你每分钟做一次这样的请求呢？您将快速使用您的所有API使用限制！

UPDATE

好，多试验几次后，我现在看到下面的“规则”（却无法发现它在任何地方的文档，因此请注意确保如果规则或只是假设）：当用户星新东西，每个请求页面的结果都包含与之前相比不同的ETag值，并且不再具有状态304！这意味着只需要首页并检查状态就足够了。如果它的304（未修改），我们不需要检查下一页，也就是说我们已经完成了，因为任何页面都没有改变。这是正确的方法还是巧合？

Answer 1

当内容已更改1时，我们确实返回Link响应标头中的分页关系。由于我们不支持该调用的since参数，因此您需要按最近的结果进行排序，并为最后已知的ID或时间戳（根据排序条件）维护客户端游标，并在显示时停止分页在你的分页结果中。有条件的请求会让你知道第1页是否已经改变。

我们还没有解决返回我们列表方法的方法，但真正低技术的解决方案是将页面大小设置为1，获取rel=last链接关系并检查其参数值page。

希望有所帮助。