Connectedness有什么好处？

Question

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

但真的有用吗？

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

除非你正在编写一个愚蠢的网络爬虫（甚至我不知道），你仍然需要教会客户端每个链接在编译时的含义。也就是说，客户端需要知道“书签URI”返回书签资源的URI，然后将控制权交给特殊的书签处理算法。你不能盲目地将链接传递给一些通用的客户端方法。既然你需要这个逻辑：

1. 客户端在运行时计算URI与在编译时提供URI（使http://example.com/users/bookmarks成为根URI）之间有什么区别？

2. 为什么使用http://example.com/users/joe/bookmarks/2首选id="2"进行关联？

我能想到的唯一好处是能够随着时间的推移改变非root URI的路径，但这会破坏缓存的链接，所以无论如何它都不是真正可取的。我错过了什么？

Answer 1

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

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

我最后的想法是，通过将其视为静态的链接网络，您可能会过度简化连通性的概念。当然，客户需要了解资源中某些链接的可能存在，但不一定需要知道跟踪该链接的确切后果。

让我试试一个例子：用户正在为某些商品下订单，他们已准备好提交购物车。提交链接实际上可能会转到两个不同的地方，具体取决于订单是在本地还是国际递送。也许超过一定值的订单需要经过一个额外的步骤。客户端只知道它必须遵循提交链接，但它没有编译知道下一步的去向。当然，您可以构建一个通用的“下一步”类型的资源，以便客户端可以明确地获得这些知识，但通过让服务器动态地提供链接，您可以引入更少的客户端 - 服务器耦合。

我认为资源中的链接是占位符，用户可以选择做什么。谁将完成工作以及如何完成工作取决于服务器对该链接的附加信息。

Answer 2

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

补充：好吧，整个观点始于你没有在编译时指定如何以硬编码的方式将URI转换为uids，而是你可以使用字典或解析来做到这一点，为你提供更多灵活的系统。

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

当然，整个论点的反面是，在简单的UID系统上实现基于URI的系统需要更长的时间。但是如果你的应用程序将被其他人定期使用，那么初始时间投资将会有很大的回报（可以说它具有良好的可扩展性ROI）。

补充说：另一个在某种程度上是品味的点是URI本身将是一个更好的名称，因为它传达了逻辑和定义的含义

Answer 3

我会添加自己的答案：

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