我对定义'好的REST'URI感到不舒服。该方案是包含待售产品的现有站点。您可以在多个视图中查看数据，向下钻取层次结构，但基本上是cat1/cat/ products或cat 2/cat3/products或类别1到4的任意组合。其他产品视图基于搜索。
你如何形成URI？
products/??????
答案 0 :(得分：1)
您可以在URI中使用查询字符串：
/products?categories=german,adult,foo,bar
为了避免多个URI，您可以强制执行某些逻辑，例如服务器端类别的字母顺序，因此对上述URI的请求实际上会通过301 Moved Permanently响应重定向到：
/products?categories=adult,bar,foo,german
要使上述查询部分模式在浏览器中工作，您必须使用JavaScript从任何html表单生成查询 - 如果您想避免该特定问题，您可以这样做：
/products?cat1=adult&cat2=bar&cat3=foo&cat4=german
答案 1 :(得分：1)
设计了一个遵循REST架构原则的网站，我的建议是根据您的服务器设计决定您的URI结构，即服务器将如何解析传入的URI并提供相应的资源。 / p>
REST设计的一个原则（我认为）是你的用户/客户永远不必形成一个URL来查找资源，他们会读取一些描述资源的超文本（即HTML），识别他们想要的东西，并从超文本中获取适当的链接（例如，在HTML中，标记的href属性包含URL，也可以是随机字符串。
同样，在我看来，如果您的应用程序要求用户/客户端能够对任意命名的类别执行搜索，则可能不适合使用RESTful设计的界面。
答案 2 :(得分：0)
是 - 这里的问题是您没有资源的唯一ID，因为：
products/cat1/cat4
实际上与
页面相同products/cat4/cat1
（大概是用cat1和cat4标记的所有内容的视图，或者来自cat1和cat4的所有匹配）
如果你的类别被组织成一个层次结构，你会知道“cat6”是“cat1”的孩子，例如。
所以你的两个选择是
1）强制执行类别的自然顺序
或
2）有两个不同的URI本质上指向同一个资源（301永久重定向到您的首选资源）。