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

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

HTTP有很好的范围头，也适合分页。你可以发送

Range: pages=1

只有第一页。这可能会迫使您重新考虑什么是页面。也许客户想要不同范围的产品。Range头也可以用于声明订单:

Range: products-by-date=2009_03_27-

让所有的产品更新日期或

Range: products-by-date=0-2009_11_30

让所有的产品都比这个日期更老。'0'可能不是最好的解决方案，但RFC似乎想要一些范围开始。可能部署的HTTP解析器不会解析units=-range_end。

如果标题不是一个(可接受的)选项，我认为第一个解决方案(所有在查询字符串)是一种处理页面的方式。但是，请规范化查询字符串(按字母顺序排序(键=值)对)。这就解决了?A =1&b=x" and "?B =x&a=1"的微分问题。

我在我的项目中使用以下url:

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

意思是"给我第二页按field1升序，然后按field2降序"或者如果我需要更大的灵活性，我会使用:

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

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

我一直使用选项1的风格。在我的例子中，缓存并不是一个问题，因为数据经常变化。如果您允许页面的大小是可配置的，那么数据就不能被缓存。

我不觉得url难记或不干净。对我来说，这是查询参数的一个很好的使用。资源显然是一个产品列表，查询参数只是告诉您希望如何显示该列表—排序和哪个页面。

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

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