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。

希望有所幫助。