连通性的好处是什么？

Question

面向资源的架构（ROA）定义的连通性的好处是什么？我理解它的方式，Connectedness的关键是能够仅使用根URI来爬行整个应用程序状态。

但是真的有用吗？

例如，假设HTTP GET http://example.com/users/joe返回到http://examples.com/uses/joe/bookmarks的链接。

除非你正在编写一个愚蠢的网络爬虫（即使那么我想知道），你仍然需要教客户每个链接在编译时的含义。也就是说，客户端需要知道“书签URI”向书签资源返回URI，然后将控制权交给特殊的书签处理算法。您不能仅仅将链接盲目地传递给某些常规客户端方法。因为你需要这个逻辑反正：

1. 什么是客户端在运行时与在编译时提供它搞清楚的URI的区别（使http://example.com/users/bookmarks根URI）？

2. 为什么使用http://example.com/users/joe/bookmarks/2优先使用id="2"？

我能想到的唯一的好处是改变非根URI的路径，通过时间的能力，但这种休息缓存链接，以便它不是一个真正理想的反正。我错过了什么？

Answer 1

你是对的，改变尤里斯是不可取的，但它确实发生，并且使用完整的Uris而不是构建它们使变更更容易处理。

另一个好处是您的客户端应用程序可以轻松地从多个主机检索资源。如果您允许客户端构建URI，则客户端需要知道某些资源驻留在哪个主机上。当所有资源都存在于单个主机上时，这并不是什么大问题，但当您汇总来自多个主机的数据时，这变得更加棘手。

我最后的想法是，也许你是通过将它看作一个静态的链接网络来简化连通性的概念。当然，客户需要知道资源中某些链接是否存在，但不一定需要确切知道遵循该链接的后果。

让我尝试一个举例：用户正在下订单的一些项目，他们准备提交他们的购物车。提交链接实际上可能会根据订单是在本地还是在国际上交付而转到两个不同的地方。也许订单超过一定的价值需要经过一个额外的步骤。客户只知道它必须遵循提交链接，但它没有编译知道下一步要去哪里。当然你可以建立一个通用的“下一步”类型的资源，这样客户端可以明确地了解这些知识，但通过让服务器动态地传递链接，你可以引入更少的客户端 - 服务器耦合。

我认为资源中的链接是占位符，用户可以选择做什么。谁来完成这项工作，以及它将如何完成取决于服务器连接到该链接的URI。

Answer 2

它更容易扩展，您可以编写小应用程序和脚本，以便与核心应用程序一起工作。

补充：好的，整个观点开始于你没有在编译时指定如何以硬编码的方式将URI转换为uid的想法，相反，你可以使用字典或解析来做到这一点，给你一个很大的更灵活的系统。

然后后来说别人决定改变URI语法，那个人可以编写一个小的脚本来翻译URI，而不必接触你的核心应用程序。另一个好处是，如果你的URI是逻辑上的其他用户，即使是在公司场景中，也可以轻松地编写Mash-ups来使用你的系统，而无需接触你原来的应用程序，甚至不需要重新编译它。

当然，整个论点的反面是，需要更长的时间才能通过简单的UID系统实现基于URI的系统。但是，如果您的应用程序将被其他人以常规方式使用，那么最初的时间投资将大大回报（可以说它具有良好的可扩展性ROI）。

补充：另一点是口味在一定程度母校是URI本身将是一个更好的名字，因为它传达了一个合乎逻辑的和定义的含义

Answer 3

我要添加自己的答案：

1. 要容易得多遵循比你自己构建它们的服务器提供的URI。由于资源关系变得太复杂而无法用简单的规则来表达，因此尤其如此。在服务器中编写逻辑比在众多客户端中重新实现它更容易。
2. 即使单个资源URI保持不变，资源之间的关系也可能会发生变化。例如，想象谷歌地图将他们的地图块从0到100索引，从屏幕的左上角到右下角计算。如果Google地图要更改其拼贴的比例，则计算相对拼贴索引的客户端将会中断。
3. 自定义ID标识资源。通过识别如何检索资源表示，URI更进一步。这简化了只读客户端的逻辑，如Web爬虫或下载不透明资源（如视频或音频文件）的客户端。