常規(guī)的分頁方式

API處理分頁看似簡單，實際上暗藏危機。最常見的分頁方式，大概是下面這樣的

/users/?page=1&limit=5//服務(wù)端返回

最理想的情況下，客戶端請求第一頁的5條數(shù)據(jù)，服務(wù)端如常返回，比如下圖:

拿Twitter的圖用一下，假設(shè)我們的數(shù)據(jù)庫有10條數(shù)據(jù)，按照5條一頁，正好有2頁。
在理想情況下，客戶端拉取數(shù)據(jù)時不會出現(xiàn)任何異常。但，這僅僅是正常情況,如果此時剛好有2條新數(shù)據(jù)插入。

數(shù)據(jù)庫記錄變?yōu)?3。原來第二頁的數(shù)據(jù)是[5, 4, 3, 2, 1]，現(xiàn)在變?yōu)閇7, 6, 5, 4, 3]，我們再一次拿到了第一頁的數(shù)據(jù)。同理，如果用戶在拉取數(shù)據(jù)時正好有數(shù)據(jù)被刪除，一樣會出現(xiàn)類似的問題。

根據(jù)item_id分頁

要解決此類問題，就不能使用常規(guī)的分頁方式?，F(xiàn)在，我們換一個思路，客戶端拉取數(shù)據(jù)時不再傳page,改為item_id，我們就把它稱為max_id

/users/?max_id=5&limit=5

此時服務(wù)端就知道我們上次拉取到了item_id為5的數(shù)據(jù)，繼續(xù)在它后面拉取5條， 如下圖:

數(shù)據(jù)可以正常取回，不會再出現(xiàn)上一頁中的[6,7]。好了，讓我們再一次假設(shè)，此時又有8條數(shù)據(jù)插入了數(shù)據(jù)庫。再一次獲取數(shù)據(jù)

可以看出，再一次出現(xiàn)問題，我們又拿到了上一頁的[10,9]。所以，我們得告訴服務(wù)端，上一次拿到哪一條數(shù)據(jù)了。所以繼續(xù)增加一個since_id字段。

恩，再一次取出了正確的數(shù)據(jù)?？赡苣阌X得一切都正常了，但還是隱藏了一個致命的缺陷。

上面的數(shù)據(jù)能正常獲取，是因為數(shù)據(jù)都是一個有序的集合，如果數(shù)據(jù)無序，且從數(shù)據(jù)庫取出時需要按照某個字段排序，那么一切再次打回原點:所有的分頁都亂了。

如何設(shè)計分頁API

可以看出，兩種分頁方式都存在問題。所以這兩種需求都是必要的，我們需要根據(jù)不同的業(yè)務(wù)場景使用不同的分頁方式。

為了不造成客戶端的麻煩，我們對api的分頁做了一些更改。

{

我們由服務(wù)端來決定如何分頁,前端需要做的，只是把next字段直接拼接到url中，這樣就可以應(yīng)付各種分頁情況。

總結(jié)

常規(guī)的分頁方式不能應(yīng)付經(jīng)常變更的數(shù)據(jù)，sinceid和maxid的方式不能應(yīng)付有其他排序的數(shù)據(jù)。大概就是這個樣子，沒有一種萬能的分頁方案，我們只能針對具體的業(yè)務(wù)場景去設(shè)計一個彈性的API來處理復(fù)雜的分頁場景。

ps: 最初我們想到的分頁方案，是直接使用item_id作為拉取數(shù)據(jù)的依據(jù)，后來看到Twitter的文章，感覺有更好的分頁方案，又懶得畫圖，所以就直接搬Twitter分頁的部分了。:)

參考鏈接:
Working with Timelines

創(chuàng)作挑戰(zhàn)賽新人創(chuàng)作獎勵來咯，堅持創(chuàng)作打卡瓜分現(xiàn)金大獎

總結(jié)

以上是生活随笔為你收集整理的分页第一页用0还是1_如何设计api分页的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。