REST Web应用程序中的分页

这是对该问题的更一般化的表述（省去了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
我个人认为使用此方法没有问题，但是有人警告我这不是一个好方法（他没有给出原因，因此，如果您知道为什么不建议这样做，请告诉我）

任何建议，意见，批评都将受到欢迎。谢谢。

我认为版本3的问题更多是“观点”问题-您将页面视为资源还是页面上的产品。

如果您将页面视为资源，那是一个很好的解决方案，因为对页面2的查询将始终产生页面2。

但是，如果您将页面上的产品视为资源，则可能会遇到页面2上的产品可能会更改（删除了旧产品等）的问题，在这种情况下，URI并不总是返回相同的资源。

例如，客户存储了指向产品列表页面X的链接，下次打开链接时，所涉及的产品可能不再位于页面X上。

我同意Fionn的观点，但是我要进一步说，页面对我来说不是资源，而是请求的属性。这使我只选择了选项1查询字符串。感觉不错。我非常喜欢Twitter API的结构结构。不太简单，也不太复杂，有据可查。不管是好是坏，当我以一种方式与另一种方式做事时，这是我的“去”设计。

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”的区分问题。

在您的应用程序将分页视为一种用于产生同一资源的不同视图的技术的情况下，选项1似乎是最好的。

话虽如此，URL方案相对来说并不重要。如果您将应用程序设计为超文本驱动的（因为所有REST应用程序都必须是按定义的），那么您的客户端将不会自己构造任何URI。相反，您的应用程序将提供到客户端的链接，客户端将跟随它们。

客户可以提供的一种链接是分页链接。

所有这一切的令人愉快的副作用是，即使您改变了对分页URI结构的看法并在下周实施了完全不同的操作，您的客户也可以继续工作而无需进行任何修改。

我一直使用选项1的样式。由于我的情况下数据经常更改，因此缓存并不是一个问题。如果您允许页面的大小是可配置的，那么将无法再次缓存数据。

我发现该网址难以记住或不干净。对我来说，这是查询参数的一种很好的用法。该资源显然是一个产品列表，查询参数只是在告诉您希望列表如何显示-排序以及哪个页面。

奇怪的是没有人指出选项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再次变得丑陋:)

我更喜欢使用查询参数offset和limit。

offset：用于集合中项目的索引。

限制：用于项目计数。

客户端可以简单地继续更新偏移量，如下所示

offset = offset + limit

用于下一页。

该路径被视为资源标识符。页面不是资源而是资源集合的子集。由于分页通常是GET请求，因此查询参数最适合分页而不是标头。

参考：https : //metamug.com/article/rest-api-developers-dilemma.html#Requesting-the-next-page

在寻找最佳实践时，我遇到了这个网站：

http://www.restapitutorial.com

在资源页面中，有一个下载.pdf的链接，其中包含作者建议的完整REST最佳实践。其中除其他外，还有关于分页的部分。

作者建议同时使用Range标头和查询字符串参数来增加支持。

请求

HTTP标头示例：

Range: items=0-24

查询字符串参数示例：

GET http://api.example.com/resources?offset=0&limit=25

其中offset是起始物料编号，limit是要返回的最大物料数量。

响应

响应应包含一个Content-Range标头，该标头指示要返回多少项目以及尚待检索的总项目数

HTTP标头示例：

Content-Range: items 0-24/66

Content-Range: items 40-65/*

在.pdf中，还有一些针对更具体情况的建议。

我目前在ASP.NET MVC应用程序中使用类似于此的方案：

例如 http://application/products/by-date/page/2

具体来说是： http://application/products/Date/Ascending/3

但是，我对以这种方式在页面中包括分页和排序信息并不十分满意。

项目列表（在这种情况下为产品）是可变的。也就是说，下次有人返回包含分页和排序参数的网址时，他们得到的结果可能已更改。因此，http://application/products/Date/Ascending/3作为指向定义的，不变的产品集的唯一url 的想法丢失了。

我倾向于同意“页面”并不是真正的资源。另一方面，选项3更干净，更易于阅读，并且用户更容易猜出，甚至在必要时也可以键入。我在选项1和3之间感到困惑，但是没有任何理由不使用选项3。

同样，尽管它们看起来不错，但正如有人提到的那样，使用隐藏参数而不是查询字符串或URL段的一个缺点是用户无法添加书签或直接链接到特定页面。取决于应用程序，这可能是问题，也可能不是问题，只是一些需要注意的问题。

我之前使用过解决方案3（我写了很多django应用）。而且我认为这没有任何问题。它与其他两个一样可生成（以防您需要进行大量刮擦等操作），并且看起来更干净。另外，您的用户可以猜测url（如果它是面向公众的应用程序），并且人们喜欢能够直接转到他们想要的地方，并且url猜测可以增强功能。

我在项目中使用以下网址：

http://application/products?page=2&sort=+field1-field2

这意味着-“给我页面第二页，按字段1升序排列，然后按字段2降序排列”。或者，如果我需要更大的灵活性，可以使用：

http://application/products?skip=20&limit=20&sort=+field1-field2

我在以下模式中使用以获得下一页记录。 http：// application / products？lastRecordKey =？＆pageSize = 20＆sort = ASC

RecordKey是在DB中保存顺序值的表的列。一次只能从DB读取一页数据。pageSize用于确定要提取多少条记录。sort用于按升序或降序对记录进行排序。