頁大小 + 頁號和起始位置 + 條數☑
分頁 api 設計
如果要取得資源列表，往往會遇到乙個問題：分頁，這時候的 api 該如何設計呢？以 restful api 為例來分析。
先開啟，找到repository_search_url ""；
這裡第乙個問題是 uri 的設計，我們分頁時，分頁資訊其實是查詢引數，不應該成為 uri 的一部分。因此，我們得到repositories?分頁引數。
接下來，我們來看分頁引數怎麼設計。我們有兩種方案：一種是「頁大小 + 頁號」，一種是「起始位置 + 條數」。
哪種更好呢？推薦使用後者，因為頁碼在本質上是前端的概念，前端可以按照每次 100 項向後端請求資料，但是展示給使用者的時候用 10 項每頁展示。如果我們在 api 中規定了頁號，那麼使用起來容易導致困惑。甚至，前端也可能完全不分頁，而是使用「無限滾動」瀑布流式載入資料，這種模式下要對映出乙個頁碼的概念，也會很彆扭，而「起始位置 + 條數」的模式則適應性更強，在兩種概念下都很容易理解。同時，在資料庫中的分頁也是完全相同的模式，可以直接把它們傳給資料庫去查詢。
命名方面，在乙個組織內要盡量統一。如果有以前的 api，要避開重新命名引數；條數避免命名為length，因為它和資料長度、字元長度同名，容易干擾其它**和第三方庫。
返回值，狀態碼要遵循規範，列表中沒有資料時狀態碼為 200，並返回空陣列。而有資料時，要返回乙個和符合條件的資料列表。
可以在響應頭中增加自定義頭，如上述 github api 中自定義響應頭link記錄分頁導航資訊，以及其它一些x-github-×××自定義屬性。
對於沒有快取機制的請求，可以定義乙個x-record-count，用它來表明符合條件的總條數，前端可以儲存，意味著沒必要每次請求都重新求一次元資料，可以減少伺服器的壓力，這樣把請求拆分成兩個：乙個用來獲取條目列表(get/repositories)，乙個用來獲取相關的元資料(head/repositories)，相關的元資料只需在初始化時呼叫一次即可，不用每次都觸發。當然，這種方式可能導致新增的資料不能在換頁時立刻重新整理出來。如果確實需要頻繁重新整理總數，可以選擇使用最初的元資料、資料列表合一的 api，也可以寫乙個邏輯定時 head 請求來重新整理資料。
api 的設計取決於需求，沒有一勞永逸的解決方案，適合業務需求的 api 才是友好的 api。
訂單系統設計 分頁查詢
1.2 查詢條件設計 二 技術方案 2.2 mysql es架構 三 db規範 產品設計不合理是導致深度分頁查詢的乙個重要原因，比如下圖所示的深度隨機跳頁設計方案，如果沒有特殊原因，正常情況下應避免使用。一方面，隨機跳頁實際意義有多大有待考究 另一方面，隨機性會加大後端的難度，如果隨機跳頁的頁碼很大...
GradView基礎樣式設計 分頁 序號列
首先，gradview 72絕技在部落格上很出名，但對於新手的我來說顯得過於高大上，很多功能現在用不上也有點難以掌握。但從.net平台拖拉控制項開始，進入到gradview的初級階段還是很容易的。別人給我演示了下拖拉控制項，並設定了下gridview的一些屬性，就有了以上 有幫我完善了下後台 就很輕...
API分頁最佳實踐
提供api分頁功能的時候,有一些最佳實踐值得分享,列出來如下 1.對於合格資料量特別大的情況 比如表中資料1000w,where之後還有30w這種,禁止使用 limit m,n 這種分頁,越翻越慢,從而導致mysql消耗資源過高,此類分頁是查出前xx頁,捨棄掉,如果 limit 100000,2,會...