REST 中的 category/category_id/item_id 和 category?category_id={}&item_id={} 有什么区别？答案

【问题标题】：What is the difference between category/category_id/item_id and category?category_id={}&item_id={} in REST?REST 中的 category/category_id/item_id 和 category?category_id={}&item_id={} 有什么区别？
【发布时间】：2010-12-19 03:29:48
【问题描述】：

我刚开始研究 REST，想知道这两种表示形式之间的基本区别是什么。第一个对我来说看起来不错，第二个必须传递一些属性值，但底层逻辑似乎沸腾到几乎相同的东西（虽然我可能弄错了）

http://url/category/category_id/item_id

与

http://url/category?category_id={12}&item_id={12334}

【问题讨论】：

标签： rest representation restful-url

【解决方案1】：

我认为您对 REST 是什么有一些基本的误解。

用于访问资源的 URL 确实是一个细节，实际上对客户端来说并不重要。如果客户遵循作为 REST 原则之一的HATEAOS 原则，那么无论如何，URL 都应该真正被客户“发现”。

基本上你是对的：URL 可以代表你最终暴露的资源，但正如我所说，这确实是一个细节，在许多情况下归结为偏好URL 你暴露的东西。 HATEOAS 的重点是允许您随意更改用于访问资源的 URL，而不会影响与您现有服务相冲突的客户端。

以下 URL 可能会帮助您了解使服务真正成为 RESTful 的一些属性：

[免责声明：仅仅因为 HATEAOS 是 REST 的一项原则，并不容易做到。你会发现网络上的大多数服务根本没有严格遵循这个原则，他们的文档中充满了 URL 模板就证明了这一点；不是在理想世界中记录服务的方式。我正在努力寻找真正 RESTful 服务和客户端的好例子...]

【讨论】：

我对 REST 的批评之一是它对 HATEAOS 的严格性，尤其是与已发布的公共 Web 服务相关。我理解它的好处，但它忽略了通过可以组合并输入浏览器的 URL 获得的改进采用的好处。这并不意味着 HATEAOS 在真空中并不理想，只是纯粹主义者 RESTful/HATEAOS 忽略了采用率的价值和实现它的简单性。在我的完美世界中，80% 的 RESTful 系统将是超文本驱动的，而另外 20% 则不会。

【解决方案2】：

如果您单击标签 restful-url 中的按钮，您会从该站点获得一个很好的链接，解释这两种样式之间的区别：

How to obtain REST resource with different finder "methods"?

【讨论】：

【解决方案3】：

代理应该可以推理资源结构：

基于 URL，并且
基于资源请求返回的链接。

第二种表示的问题在于，它可以被视为一组无序的键和值，没有真正的结构/层次结构。

【讨论】：

所以你的意思是说第一个比第二个更受欢迎？我的意思是，我真的很喜欢第一个 - 它给事物带来了秩序，但我不确定使用第二个是否有任何优势。顺便说一句，感谢您提出无序键的逻辑。
而且我假设如果存在任何不能直接表示为层次结构一部分的附加参数，则应该使用第二种表示。例如，最好将“给我一件红色的中等大小的物品”说成url/item_id?color=red&size=medium。第一个表示在这里根本没有意义。我说的对吗？
@David：虽然你的第二个断言是正确的，但你的第一个断言不是。纯 RESTful 客户端中的推理应基于内容类型和关系进行，两者都应使用资源表示中返回的链接进行通信。