REST URI 定义
我无法适应定义“好的 REST”URI。该场景是一个包含待售产品的现有站点。您可以在多个视图中查看数据，深入层次结构，但基本上是 cat1/cat/products 或 cat 2/cat3/products 或类别的任意组合 1至 4. 其他产品视图基于搜索。
如何形成 URI？
products/??????
I can't get comfortable with defining 'good REST' URIs. The scenario is an existing site with products for sale. You can view data in a number of views, drilling down a hierarchy, but basically cat1/cat/ products, or cat 2/cat3/products or any combination of categories 1 to 4. The other products view is based on a search.
How do you form the URI's?
products/??????
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
在设计了一个遵循 REST 架构原则的站点后，我的建议是仅根据服务器设计来根据 URI 结构做出决定，这就是服务器如何解析传入的 URI 并提供相应的资源。
REST 设计的一个原则（如我所见）是，您的用户/客户端将永远不必形成 URL 来查找资源，他们将改为读取一些描述资源的超文本（即 HTML），识别他们想要的内容，并获取来自超文本的适当链接（例如，在 HTML 中，标签的 href 属性保存 URL，它也可以是随机字符串。
同样，在我看来，如果您的应用程序要求用户/客户端如果能够搜索任意命名的类别，那么可能不适合采用 REST 设计的界面。
Having designed a site that follows the principles of the REST architecture, my advice is to base your decision on your URI structure solely on your server design, that is how your server will parse an incoming URI and deliver the corresponding resource.
One principle of REST design (as I see it) is that your users/clients will NEVER have to form a URL to find a resource, they will instead read some hypertext (i.e. HTML) which describes resources, identify what they want, and get the appropriate link from the hypertext (for example, in HTML, the href attribute of the tag holds the URL, which could just as well be a random string of characters.
Again, in my opinion, if your application requires that a user/client be able to perform searches for arbitrarily named categories, it's probably not suitable to have a RESTfully designed interface.
您可以在 URI 中使用查询字符串：
为了避免多个 URI，您可以在服务器端强制执行一些逻辑，例如按类别的字母顺序排序，这样对上述 URI 的请求实际上会通过 301 Moved Permanently 响应重定向到
：上面的查询部分模式要在浏览器中工作，您将必须使用 JavaScript 从任何 html 表单生成查询 - 如果您想避免该特定问题，您也可以这样做：
You can use use a query string in your URI:
In order to avoid multiple URIs you could enforce some logic like alphabetical ordering of categories on the server side so a request to the above URI would actually redirect via a 301 Moved Permanently response to:
For that above query part pattern to work in browsers you will have to use JavaScript to generate the query from any html forms - you could, alternatively, do it like this if you wanted to avoid that particular problem:
是的 - 这里的问题是您没有资源的唯一 ID，因为：
实际上是同一页面
（大概是用 cat1 和 cat4 标记的所有内容的视图，或来自 cat1 和 cat4 的所有匹配项）
如果您的类别在例如，组织成层次结构，您会知道“cat6”是“cat1”的子级。
因此，您的两个选择是
1) 强制类别的自然顺序
或
2) 有两个不同的 URI 实质上指向同一资源（使用 301 永久重定向到您的首选资源）。
Yes - the problem here is that you don't have a unique ID for the resource because:
Is actually the same page as
(Presumably a view of everything tagged with cat1 and cat4, or all matches from cat1 and cat4)
If your categories where organised into a hierarchy you would know that "cat6" is a child of "cat1", for example.
So your two options would be
1) Enforce a natural order for the categories
or
2) Have two different URI's essentially pointing to the same resource (with a 301 permanant redirect to your preferred resource).