2

面向资源的架构 (ROA) 定义的连通性有什么好处?按照我的理解,连通性的关键是能够仅使用根 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 的路径,但这会破坏缓存的链接,因此无论如何它并不是真正可取的。我错过了什么?

4

3 回答 3

1

你是对的,改变 Uris 是不可取的,但它确实发生了,使用完整的 Uris 而不是构造它们会使更改更容易处理。

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

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

让我举个例子:一个用户正在为一些物品下订单,他们准备提交他们的购物车。提交链接实际上可能会转到两个不同的地方,具体取决于订单是在本地交付还是在国际交付。也许超过一定价值的订单需要经过额外的步骤。客户端只知道它必须遵循提交链接,但它不知道下一步要去哪里。当然,您可以构建一个通用的“下一步”类型的资源,以便客户端可以明确地了解这些知识,但是通过让服务器动态传递链接,您可以减少客户端-服务器耦合。

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

于 2008-10-16T16:05:39.920 回答
0

它更容易扩展,您可以编写小应用程序和脚本来相当容易地与核心应用程序一起工作。

补充:嗯,整点开始于您没有在编译时指定如何以硬编码方式将 URI 转换为 uid 的想法,而是您可以使用字典或解析来做到这一点,从而为您提供更灵活的系统。

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

当然,与整个论点相反的是,在简单的 UID 系统上实现基于 URI 的系统将花费您更长的时间。但是如果你的 App 会被其他人以常规方式使用,那么最初的时间投资将获得很大的回报(可以说具有良好的基于​​可扩展性的 ROI)。

补充:另外一点在某种程度上是一个口味问题,URI 本身将是一个更好的名称,因为它传达了一个逻辑和定义的含义

于 2008-10-15T03:03:38.780 回答
0

我将添加我自己的答案:

  1. 遵循服务器提供的 URI 比自己构建它们要容易得多。当资源关系变得过于复杂而无法用简单的规则表达时,尤其如此。在服务器中编写一次逻辑比在众多客户端中重新实现它更容易。
  2. 即使单个资源 URI 保持不变,资源之间的关系也可能发生变化。例如,假设谷歌地图从 0 到 100 索引他们的地图图块,从屏幕的左上角到右下角计数。如果谷歌地图要改变他们的瓦片的比例,计算相对瓦片索引的客户端就会崩溃。
  3. Custom IDs identify a resource. URIs go a step further by identifying how to retrieve the resource representation. This simplifies the logic of read-only clients such as web-crawlers or clients that download opaque resources such as video or audio files.
于 2008-10-19T02:03:18.697 回答