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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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