這是對該問題的更一般化的表述（省去了Rails的特定部分）我不確定如何在RESTful Web應(yīng)用程序中的資源上實現(xiàn)分頁。假設(shè)我有一個名為的資源products，您認(rèn)為以下哪種方法是最好的方法，以及原因：1.僅使用查詢字符串例如。http://application/products?page=2&sort_by=date&sort_how=asc 這里的問題是我無法使用全頁緩存，而且URL也不是很干凈且易于記憶。2.使用頁面作為資源和查詢字符串進(jìn)行排序例如。http://application/products/page/2?sort_by=date&sort_how=asc 在這種情況下，看到的問題是這http://application/products/pages/1不是唯一的資源，因為使用sort_by=price會產(chǎn)生完全不同的結(jié)果，而我仍然不能使用頁面緩存。3.使用頁面作為資源和URL段進(jìn)行排序例如。http://application/products/by-date/page/2 我個人認(rèn)為使用此方法沒有問題，但是有人警告我這不是一個好方法（他沒有給出原因，所以如果您知道為什么不建議這樣做，請告訴我）任何建議，意見，批評都將受到歡迎。謝謝。
3 回答
江戶川亂折騰
TA貢獻(xiàn)1851條經(jīng)驗 獲得超5個贊
我認(rèn)為版本3的問題更多是“觀點”問題-您將頁面視為資源還是頁面上的產(chǎn)品。
如果您將頁面視為資源，那是一個很好的解決方案，因為對頁面2的查詢將始終產(chǎn)生頁面2。
但是，如果您將頁面上的產(chǎn)品視為資源，則會遇到問題，即頁面2上的產(chǎn)品可能會發(fā)生更改（刪除了舊產(chǎn)品或其他原因），在這種情況下，URI并不總是返回相同的資源。
例如，客戶存儲了指向產(chǎn)品列表頁面X的鏈接，下次打開鏈接時，所涉及的產(chǎn)品可能不再位于頁面X上。
當(dāng)年話下
TA貢獻(xiàn)1890條經(jīng)驗 獲得超9個贊
我同意Fionn的觀點，但是我要進(jìn)一步說，頁面對我來說不是資源，而是請求的屬性。這使我只選擇了選項1查詢字符串。感覺不錯。我真的很喜歡Twitter API的結(jié)構(gòu)結(jié)構(gòu)。不太簡單，也不太復(fù)雜，有據(jù)可查。不管是好是壞，當(dāng)我以一種方式與另一種方式做事時，這是我的“可行”設(shè)計。
- 3 回答
- 0 關(guān)注
- 512 瀏覽
添加回答
舉報
0/150
提交
取消