上下文：假设我们想要定期检索给定用户的每个已加星标的存储库列表（每天，每小时或几分钟）。
至少有两种方法可以做到这一点：
1）执行GET到https://api.github.com/users/evereq/starred并在“链接”响应标题中使用带有rel ='next'的Url来获取下一页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）中所拥有的与我们如何检测何时停止的方式相关的问题在您使用条件请求时不再有效！
即。使用方法1），当您使用条件请求时，根本不会获得链接响应标头。 因此，您需要再执行一个页面大于您已经拥有ETag的页面的请求，并且看到它返回0结果并且您知道已完成。这样你基本上“浪费”了一个请求到Github API（因为它错过了条件请求标头）。
与方法2相同，在状态为304的每个请求中基本上都有0个响应...再次，要知道你已经完成，你需要至少再做一个返回0结果的额外请求。
所以问题是：当我们使用Github API不发回链接响应头的事实来执行条件请求时（至少使用ETag查询结果状态304）我们怎么知道何时停止分页？这是Github API实现中的错误还是我错过了什么？
我们不知道最大页码，所以为什么要停止我们应该再执行一次“浪费”请求并检查我们是否得到0结果！
我也找不到如何查询Github的星号存储库总数（所以我可以计算我应该在建议中迭代多少页），就像响应中不包含“X-Total-Count”这样的东西一样我知道何时停止使用简单的数学来计算页数。
任何想法如何保存那个（'结束'）请求并仍然使用条件请求？
如果你每天都做一次请求，可以接受这样的浪费，但是如果你每分钟提出这样的请求怎么办？您将快速使用所有API使用限制！
更新
嗯，经过几次测试之后，我看到现在跟随“规则”（但无法在文档中的任何地方找到它，所以请注意确定它的规则还是只是假设）：如果用户将某些新内容称为新的，那么每个结果都是如此请求页面包含与以前相比的不同ETag值，并且不再具有状态304！这意味着只需要请求第一页并检查状态就足够了。如果是304（未修改），我们不需要检查下一页，即我们已完成，因为任何页面都没有更改。这是正确的方法还是巧合？
答案 0 :(得分：1)
当内容发生变化1时，我们确实在Link响应标头中返回分页关系。由于我们不支持该调用的since参数，因此您需要按最新结果排序，并为最后一个已知ID或时间戳维护客户端游标（根据您的排序条件）并停止分页显示在您的分页结果中。有条件请求只会让您知道Page 1是否已更改。
我们还没有找到一种方法来返回我们列表方法的计数，但一个非常低技术的解决方案是将页面大小设置为1，抓住rel=last链接关系并检查其{{1参数值。
希望有所帮助。