我同意Fionn的观点，但我还要进一步说明，对我来说Page不是资源，而是请求的属性。这使得我只选择选项1查询字符串。感觉很好。我真的很喜欢Twitter API的结构。不太简单，也不太复杂，有很好的文档。无论是好是坏，这是我的“go to”设计，当我在做某件事的一种方式和另一种方式之间犹豫不决时。

我认为版本3的问题更多的是一个“观点”问题——你把页面看作资源还是页面上的产品。

如果将页面视为资源，这是一个完美的解决方案，因为对第2页的查询总是会返回第2页。

但是，如果您将页面上的产品视为资源，那么第2页上的产品可能会发生变化(旧产品被删除或其他)，在这种情况下，URI并不总是如此 返回相同的资源。

例如，客户存储了一个到产品列表X页的链接，下次该链接被打开时，问题产品可能不再在X页。

我使用in下面的模式来获得下一页记录。 http://application/products?lastRecordKey=?&pageSize=20&sort=ASC

RecordKey是数据库中保存顺序值的表的列。这用于一次只从DB中获取一个页面数据。 pageSize用于确定获取多少条记录。Sort用于按升序或降序对记录进行排序。

为了寻找最佳实践，我看到了这个网站:

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文件中，还有一些针对更具体情况的其他建议。

奇怪的是，没有人指出选项3的参数是按特定顺序排列的。 http / /应用程序/产品/日期/降/名称/升/页面/ 2 而且 http / /应用程序/产品/名称/升/日期/降/页面/ 2

指向相同的资源，但有完全不同的url。

对我来说，选项1似乎是最可接受的，因为它清楚地区分了“我想要什么”和“我想要什么”(它甚至在它们之间有问号，哈哈)。全页面缓存可以使用完整的URL实现(所有选项都会遇到相同的问题)。

使用参数在URL方法的唯一好处是干净的URL。尽管你必须想出一些方法来编码参数并无损地解码它们。当然，你可以使用URLencode/decode，但这将使url再次丑陋:)

我以前用过解决方案3(我写了很多django应用程序)。我不认为这有什么问题。它就像其他两个一样可生成(以防你需要做一些大规模的刮擦或类似的事情)，它看起来更干净。另外，你的用户可以猜网址(如果它是一个面向公众的应用程序)，人们喜欢能够直接去他们想去的地方，猜网址感觉很强大。