关于REST uri设计的问题。在官方web api教程中，我看到了以下uri：
Get a list of books by publication date: /api/books/date/2013-02-16
遵循其余原则，使用以下uri并不是更好吗？
/api/books?date=2013-02-16
由于
答案 0 :(得分：1)
在这种情况下，参数应该没有硬规则。有些人将它们放在URL路径中，有些人将它们添加到查询字符串中。请注意，在REST中，没有强调URL的外观。人们通过层次结构创建它们，因为在给定其域名的情况下这样做是有意义的：
/api/books/ # all books
/api/books/100 # details about the book with id=100
/api/books/mystery # all books in the mystery category
另一方面，/api/books/date/2013-02-16稍微有点牵强，再次因为人们推断资源的层次结构，并且大部分时间都在模拟他们的API，所以假设他们期望{{1}还要归还一些比/api/books/date更大的类别的书籍。但在这种情况下它并没有真正意义，所以也许这就是为什么你发现/api/books/date/2013-02-16是一个更自然的选择。
在这种情况下，我也更喜欢/api/books?date=2013-02-16。但同样，对于更好的选择没有硬性规则，例如见：REST API Best practices: Where to put parameters?
答案 1 :(得分：1)
他们是平等的。根据URI标准，路径包含标识符的层次结构部分，而查询部分包含非层次结构部分。现在，在地图缩小集合的情况下，您可以根据自己的喜好将过滤器视为分层和非分层。
顺便说一下。我更喜欢路径中的param:value解决方案，并使用斜杠结束集合（或简化集合）的URI，因此：/api/books/date:2013-02-16/，但afaik。这只是最佳实践，而非标准......： - ）
根据REST的统一接口约束，您必须将现有标准应用于自定义解决方案，这就是我们在这种情况下遵循URI标准的原因......