关于 Web 搜索分页，应当如何合理组织 uri 中的页面参数呢？

[dangyuluo]

目前网站需要做几个搜索功能，因此牵扯到了分页。在网站开发的过程中，尽量使用了 Restful 设计思想，如想获取某个用户的所有商品的时候，uri 为：

/user/41/products

当然这只能获取第一页产品，目前设定是每页 20 个。那么如果我想获取第二页的时候，有两种方案：（我知道这里不符合 Restful 了，不过向后兼容没有办法）

/user/41/products?from=20

/user/41/products?page=2

第一种方式是是将搜索起始点直接写到参数里，第二种是将需要获取的页面写到参数里。 希望大家指点一下，这两种方案有什么优缺点。

[viko16]

看数据量，像微博那种分分钟产生几百条数据的只能用 from=cursor （微博只是随便举的，他家的时间线从来没正常过..

[invoke]

楼上+1
如果不用 from 做值的话，可能会导致数据重复的问题，不过用 from 会让查询变的稍微复杂一点。如果数据量不大直接用 page 比较简单方便。

[LeeSeoung]

page+size

[lgpqdwjh]

page & pagesize

[littleylv]

page=1&pageSize=20

[jziwenchen]

有啥差别？

[vjnjc]

@viko16 借楼问一下，这种在不同时间 response 会变的接口，能够基于时间来做判断么?
比如 from={timestamp}这样的？
还是一定要用 from={unique-key}这样的格式？

[learnshare]

?page=2&size=10
每页 10 个，取第二页（第 10~19 项）

[mcfog]

from=20 相当于 offet=20 吧，我个人的话任何时候都不会做单独这个参数的分页

page （如果需要自定义，加上 pageSize ）的优点在于可读性，尤其是如果再放到 url 里，/products/page/1/或直接 /products/1/，非常清晰

offset+limit （也就是直接在参数里指定取多少，跳过多少）的优点在于便利做加载更多、懒加载、客户端下拉等逻辑（客户端控制维度更细，前提是同步提供 limit ）

至于 cursor，里面的值应该是上一页的最后一个项目的主键 ID，而不是跳过多少条，好处是数据量大的时候能通过索引规避大 offset 带来的性能问题，问题是跳第 N 页会比较难做（实际上数据量一大跳第 N 页一定不好做）