全局资源 URI 有什么好处（即可寻址性）？

Question

使用全局唯一的 URI（如 REST 那样）引用资源与使用专有 id 格式相比有什么好处？

例如：

1. http://host.com/student/5
2. http://host.com/student?id=5

在第一种方法中，整个 URL 是 ID。在第二种方法中，只有 5 是 ID。第一种方法比第二种方法有什么实际好处？

为什么 REST（似乎）不遗余力地提倡第一种方法？

-- 编辑：

我的问题令人困惑，因为它确实问了两个不同的问题：

1. 可寻址性有什么好处？
2. 上面看到的两种 URI 形式有什么区别。

我已使用自己的帖子回答了以下两个问题。

Answer 1

当我看到这样的 uri 时，主要的是普通用户能够记住该 uri。

我们这些极客可以用问号和获取变量，但如果有人记得http://www.host.com/users/john 而不是http://www.host.com/?view=users&name=john，那将是一个巨大的好处。

Answer 2

我会回答我自己的问题：

1) 为什么 URI 很重要？

我将引用 Leonard Richardson 和 Sam Ruby 的 RESTful Web Services（ISBN：978-0-596-52926-0）：

考虑一个真正的 URI，它在“关于资源的目录”类型中命名资源 水母”：http://www.google.com/search?q=jellyfish。那个水母搜索就像 像http://www.google.com 这样的真实URI。如果 HTTP 不可寻址，或者如果 Google 搜索引擎不是一个可寻址的网络应用程序，我无法发布它 书中的 URI。我得告诉你：“打开到 google.com 的网络连接，输入‘jellyfish’ 在搜索框中，然后点击“Google 搜索”按钮。

这不是学术上的担忧。直到 1990 年代中期，当 ftp:// URIs 由于在 FTP 站点上描述文件而变得流行，人们不得不写 例如：“在 ftp.example.com 上启动匿名 FTP 会话。然后 切换到目录 pub/files/ 并下载文件 file.txt。”制作的 URI FTP 与 HTTP 一样可寻址。现在人们只写：“下载 ftp:// ftp.example.com/pub/files/file.txt。”步骤是一样的，但现在他们 可以用机器进行。

[...]

可寻址性是 Web 应用程序的优点之一。它可以很容易地 客户以原始设计师从未想象过的方式使用网站。

2) 可寻址性有什么好处？

遵循服务器提供的 URI 比自己构建它们要容易得多。当资源关系变得过于复杂而无法用简单的规则表达时，尤其如此。在服务器中编写一次逻辑比在众多客户端中重新实现更容易。

即使各个资源 URI 保持不变，资源之间的关系也可能会发生变化。例如，如果 Google 地图要更改其地图图块的比例，则计算相对图块位置的客户端将会中断。

3) URI 与自定义 ID 相比有什么好处？

自定义 ID 唯一标识资源。 URI 通过告诉您在哪里可以找到它更进一步。这简化了客户端逻辑。

Answer 3

主要是搜索引擎优化。

在我看来，这也让它们更容易记住，而且看起来更干净、更专业。

Answer 4

第一个更美观。

技术上没有区别，但尽可能使用前者。

Answer 5

正如 Ólafur 所说，前一个网址的清晰性是一个好处。

另一个是实施灵活性。

假设学生 5 不经常更改。如果您使用 REST 样式的 url，您可以选择提供静态文件而不是运行代码。在 Rails 中，对 student/5 的第一个请求通常会在您的 Web 根目录下创建一个缓存的 html 文件。该文件用于在不接触后端的情况下为后续请求提供服务。自然地，这种方法没有什么特别之处。

后面的网址不允许这样做。静态页面的名称中不能包含 url 变量 (?, =)。

Answer 6

从 REST 的角度来看，这两个 URI 都是有效的，但是请注意 Web 缓存对查询字符串参数的处理方式非常不同。
如果您想利用缓存来发挥自己的优势，那么我建议您不要使用查询字符串参数来识别您的资源。

Answer 7

我认为这取决于您要遵守风水原则的程度。