我倾向于同意slf的观点，即“页面”并不是真正的资源。另一方面，选项3更干净，更容易阅读，用户可以更容易地猜到，甚至在必要时输入。我在选项1和选项3之间犹豫不决，但没有任何理由不使用选项3。

另外，虽然它们看起来很好，但使用隐藏参数的一个缺点，而不是查询字符串或URL段，用户不能收藏或直接链接到特定的页面。根据应用程序的不同，这可能是问题，也可能不是问题，但只是需要注意的问题。

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

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

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

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

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

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

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

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

我倾向于同意slf的观点，即“页面”并不是真正的资源。另一方面，选项3更干净，更容易阅读，用户可以更容易地猜到，甚至在必要时输入。我在选项1和选项3之间犹豫不决，但没有任何理由不使用选项3。

另外，虽然它们看起来很好，但使用隐藏参数的一个缺点，而不是查询字符串或URL段，用户不能收藏或直接链接到特定的页面。根据应用程序的不同，这可能是问题，也可能不是问题，但只是需要注意的问题。

选项1似乎是最好的，因为您的应用程序将分页视为一种为同一资源生成不同视图的技术。

尽管如此，URL方案相对来说并不重要。如果将应用程序设计为超文本驱动的(根据定义，所有REST应用程序都必须是超文本驱动的)，那么客户端将不会自行构造任何uri。相反，您的应用程序将向客户端提供链接，客户端将遵循这些链接。

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

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