我目前正在我的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的参数是按特定顺序排列的。 http / /应用程序/产品/日期/降/名称/升/页面/ 2 而且 http / /应用程序/产品/名称/升/日期/降/页面/ 2

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

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

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

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

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

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

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

选项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的想法就消失了。

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