这是对该问题的更一般化的表述（省去了Rails的特定部分）
我不确定如何在RESTful Web应用程序中的资源上实现分页。 假设我有一个叫做资源products ，下列哪一种你认为是最好的办法，为什么：
1.仅使用查询字符串
例如。 http://application/products?page=2&sort_by=date&sort_how=asc
这里的问题是我无法使用全页缓存，而且URL也不是很干净且易于记忆。
2.使用页面作为资源和查询字符串进行排序
例如。 http://application/products/page/2?sort_by=date&sort_how=asc
在这种情况下，看到的问题是http://application/products/pages/1不是唯一的资源，因为使用sort_by=price可以产生完全不同的结果， 而我仍然不能使用页面缓存。
3.使用页面作为资源和URL段进行排序
例如。 http://application/products/by-date/page/2
我个人认为使用此方法没有问题，但是有人警告我这不是一个好方法（他没有给出原因，因此，如果您知道为什么不建议这样做，请告诉我）
任何建议，意见，批评都将受到欢迎。 谢谢。
#1楼
在您的应用程序将分页视为一种用于产生同一资源的不同视图的技术的情况下，选项1似乎是最好的。
话虽如此，URL方案相对来说并不重要。 如果您将应用程序设计为超文本驱动的 （因为所有REST应用程序必须根据定义），那么您的客户端将不会自行构造任何URI。 相反，您的应用程序将提供到客户端的链接，客户端将跟随它们。
客户可以提供的一种链接是分页链接。
所有这些令人愉快的副作用是，即使您改变了对分页URI结构的看法并在下周实施了完全不同的操作，您的客户也可以继续工作而无需进行任何修改。
#2楼
HTTP具有出色的Range标头，也适用于分页。 您可以发送
Range: pages=1
只有第一页。 这可能会迫使您重新考虑什么是页面。 也许客户想要不同范围的物品。 范围标头还可以用于声明订单：
Range: products-by-date=2009_03_27-
获得比该日期更新的所有产品，或者
Range: products-by-date=0-2009_11_30
使所有产品都早于该日期。 “ 0”可能不是最佳解决方案，但RFC似乎需要一些用于范围开始的内容。 可能部署了HTTP解析器，无法解析unit = -range_end。
如果标题不是（可接受的）选项，我认为第一个解决方案（全部在查询字符串中）是一种处理页面的方法。 但是，请规范化查询字符串（按字母顺序对（键=值）对进行排序）。 这解决了“Δa＝ 1＆b ＝ x”和“Δb＝ x＆a ＝ 1”的区分问题。
#3楼
奇怪的是没有人指出选项3具有特定顺序的参数。 http // application / products / Date / Descending / Name / Ascending / page / 2和http // application / products / Name / Ascending / Date / Descending / page / 2
指向相同的资源，但具有完全不同的网址。
对我来说，选项1似乎是最可接受的，因为它清楚地将“我想要的”和“我想要的”分开（它们之间甚至有问号）。 可以使用完整URL来实现全页缓存（无论如何，所有选项都会遇到相同的问题）。
使用URL中的参数方法的唯一好处是干净的URL。 尽管您必须想出一些方法来编码参数并无损地解码它们。 当然，您可以使用URLencode / decode，但这会使URL再次变得丑陋:)
#4楼
我在项目中使用以下网址：
http://application/products?page=2&sort=+field1-field2
这意味着-“给我页面第二页，按字段1升序排列，然后按字段2降序排列”。 或者，如果我需要更大的灵活性，可以使用：
http://application/products?skip=20&limit=20&sort=+field1-field2
#5楼
我更喜欢使用查询参数offset和limit。
offset ：用于集合中项目的索引。
限制 ：用于项目计数。
客户端可以简单地继续更新偏移量，如下所示
offset = offset + limit
用于下一页。
该路径被视为资源标识符。 页面不是资源而是资源集合的子集。 由于分页通常是GET请求，因此查询参数最适合分页而不是标头。
参考： https : //metamug.com/article/rest-api-developers-dilemma.html#Requesting-the-next-page
来源：oschina
链接：https://my.oschina.net/stackoom/blog/3192688