使用全局唯一的 URI（如 REST 那样）引用资源与使用专有的 id 格式相比有什么好处？
例如：
在第一种方法中，整个 URL 是 ID。在第二种方法中，只有 5 是 ID。第一种方法比第二种方法有什么实际好处？
为什么 REST（似乎）不遗余力地提倡第一种方法？
- 编辑：
我的问题令人困惑，因为它确实问了两个不同的问题：
- 可寻址性有什么好处？
- 上面看到的两种 URI 形式有什么区别。
我已经使用自己的帖子回答了以下两个问题。
Gili
问问题
485 次
7 回答
3
当我看到这样的 uri 时，主要的事情是普通用户能够记住那个 uri。
我们的极客对问号和获取变量很好，但如果有人记得http://www.host.com/users/john而不是http://www.host.com/?view=users&name=john，那就是一个巨大的好处。
于 2008-09-29T01:25:06.490 回答
1
我将回答我自己的问题：
1）为什么URI很重要？
我将引用Leonard Richardson 和 Sam Ruby 的 RESTful Web Services (ISBN: 978-0-596-52926-0)：
考虑一个真实的 URI，它命名了“关于水母的资源目录”类型的资源：http ://www.google.com/search?q=jellyfish 。jellyfish 搜索与http://www.google.com一样是一个真实的 URI 。如果 HTTP 不可寻址，或者如果 Google 搜索引擎不是可寻址的 Web 应用程序，我将无法在书中发布该 URI。我得告诉你：“打开到 google.com 的网络连接，在搜索框中输入‘jellyfish’，然后点击‘Google 搜索’按钮。
这不是学术上的担忧。直到 1990 年代中期，当 ftp:// URI 开始流行用于描述 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 通过告诉您在哪里可以找到它更进一步。这简化了客户端逻辑。
于 2008-10-08T18:52:36.823 回答
0
主要是搜索引擎优化。
在我看来，这也使它们更容易记住，更干净，更专业。
于 2008-09-29T01:23:21.113 回答
0
第一个更美观。
从技术上讲没有区别，但尽可能使用前者。
于 2008-09-29T01:23:25.450 回答
0
正如 Ólafur 提到的，前一个网址的清晰是一个好处。
另一个是实施灵活性。
假设学生 5 不经常更改。如果您使用 REST 样式的 url，您可以选择提供静态文件而不是运行代码。在 Rails 中，对 student/5 的第一个请求通常会在您的 Web 根目录下创建一个缓存的 html 文件。该文件用于在不接触后端的情况下为后续请求提供服务。自然地，这种方法没有什么特别之处。
后来的网址不允许这样做。静态页面的名称中不能包含 url 变量 (?, =)。
于 2008-09-29T02:02:30.643 回答
0
从 REST 的角度来看，这两个 URI 都是有效的，但是只需意识到 Web 缓存对查询字符串参数的处理方式非常不同。
如果您想利用缓存来发挥自己的优势，那么我建议您不要使用查询字符串参数来识别您的资源。
于 2008-09-29T13:34:04.180 回答
-1
我认为这取决于您要遵守风水原则的程度。
于 2008-09-29T01:51:33.323 回答