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

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

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

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"的微分问题。

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

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

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

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

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

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

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

但是，我并不喜欢以这种方式在路由中包括分页和排序信息。

项目列表(在本例中为产品)是可变的。也就是说，下次有人返回包含分页和排序参数的url时，他们得到的结果可能已经改变了。因此，将http://application/products/Date/Ascending/3作为指向一组确定的、不变的产品的唯一url的想法就消失了。

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