使用全局唯一URI（如REST所做的）与使用专有ID格式引用资源有什么好处？
例如：
在第一种方法中，整个URL是ID。在第二种方法中，只有5是ID。第一种方法相对于第二种方法的实际好处是什么？
为什么REST（似乎）不顾一切地倡导第一种方法？
- 编辑：
我的问题令人困惑，因为它确实提出了两个不同的问题：
我已经使用自己的帖子回答了以下两个问题。
答案 0 :(得分：3)
当我看到像这样的普通用户时，主要的事情是能够记住那个uri。
我们的极客可以使用问号并获取变量，但如果有人记得http://www.host.com/users/john而不是http://www.host.com/?view=users&name=john，那么这是一个巨大的好处。
答案 1 :(得分：1)
我会回答我自己的问题：
1）为什么URI很重要？
我将引用Leonard Richardson和Sam Ruby的 RESTful Web服务（ISBN：978-0-596-52926-0）：
考虑一个真实的URI，它命名一个类型的资源“资源目录 水母“：http://www.google.com/search?q=jellyfish。那个水母搜索就像 一个真正的URI http://www.google.com。如果HTTP无法寻址，或者Google无法寻址 搜索引擎不是一个可寻址的Web应用程序，我无法发布它 书中的URI。我必须告诉你：“打开google.com的网络连接，输入'水母' 在搜索框中，然后点击“Google搜索”按钮。
这不是学术上的担忧。直到20世纪90年代中期，当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更进了一步。这简化了客户端逻辑。
答案 2 :(得分：0)
主要是搜索引擎优化。
在我看来，这也让他们更容易记忆，更清洁，更专业。
答案 3 :(得分：0)
第一个更美观。
从技术上讲，没有区别，但可以使用前者。
答案 4 :(得分：0)
正如Ólafur所说，前一个网址的清晰度是一个好处。
另一个是实施灵活性。
假设学生5不经常改变。如果您使用REST样式的URL，则可以选择提供静态文件而不是运行代码。在Rails中，对学生/ 5的第一个请求通常会在您的Web根目录下创建一个缓存的html文件。该文件用于提供后续请求，无需触及后端。当然，这种方法没有特定的轨道。
后来的网址不允许这样做。您不能在静态页面的名称中包含url变量（？，=）。
答案 5 :(得分：0)
这两个URI从REST角度来看都是有效的，但只是意识到Web缓存对待查询字符串参数的方式有很大不同。
如果您希望使用缓存，那么我建议您不要使用查询字符串参数来标识您的资源。
答案 6 :(得分：-1)
我认为这取决于你们如何密切关注风水的原则。