2

我试图了解使用关系类型和带有名称属性的链接之间的细微差别。

也许一个例子最能说明我的问题。考虑一个代表同行评审文章的 HAL 格式响应：

  {
    name: "Mechanics (Le mecaniche)",
    _links : {
      canonical : { href: "https://phys.org/articles/Mechanics"},
      "x:author" : [
         { href : "https://phys.org/authors/111", title : "Galileo Galilei"}
      ],
      "x:reviewer" : [
         { href : "https://phys.org/authors/222", title : "Isaac Newton"}
      ]
    }
  }

我试图用这个例子展示的关键是文章资源包含多个与同一类型资源的语义不同的关系。在此示例中，文章具有指向作为文章作者的作者的链接以及指向对文章进行同行评审的作者的链接。

在上面的示例中，我将它们定义为两种不同的关系类型。根据我对HAL 规范和Web Linking 规范的阅读，上述方法既有效又与许多示例一致。

但是...如果我将相同的响应格式化如下：

  {
    name: "Mechanics (Le mecaniche)",
    _links : {
      canonical : { href: "https://phys.org/articles/Mechanics"},
      "x:author" : [
         { name = "author", href : "https://phys.org/authors/111", title : "Galileo Galilei"},
         { name = "reviewer", href : "https://phys.org/authors/222", title : "Isaac Newton"}
      ]
    }
  }

在此示例中，我选择使用 Relation Type 来指示资源类型，并根据 Link 的 Name 属性来缩小关系的含义。

从务实的角度来看，我发现后一种方法很有吸引力。我可以想象客户端应用程序的作者使用关系类型作为资源缓存的键。在这种情况下，客户端将拥有单个作者资源缓存，而不是具有重复条目的独立作者和审阅者缓存（其中作者也是审阅者。）我意识到单个异构资源缓存可以避免这种情况和/或推送缓存对浏览器的责任（应该是恕我直言），但是......再次，这是务实的观点。许多 web 应用程序在内部处理缓存，并希望每种资源类型都有一个缓存（可能按资源类型应用不同的策略。）

我也喜欢后一种方法，因为根据HAL 规范，我可以利用链接的名称属性“作为选择共享相同关系类型的链接对象的辅助键” 。我不禁将规范中的那一行读为“......相同的资源类型”。

最后但并非最不重要的一点是，我想知道这两种方法将如何影响这些链接的文档。具体来说，作为“扩展关系类型”，“x:author”和“x:reviewer”关系类型应该在其 url 上有可用的文档（直接或通过 CURIE）。如果我遵循后一种方法，使用链接名称属性，那么文档将需要描述资源关系的命名变体的子部分。

我进行了一些搜索，但没有找到任何使用链接名称属性的示例。我很想看到一些，和/或从作者那里听到更多关于该领域意图的信息。

更新..

到目前为止的响应都强调关系类型旨在反映上下文与 href 处的结果之间的关系，而不是该目的地的资源类型。

这是可以理解的，但如果可能，请详细说明 Link 的 Name 属性的用途。 它与关系类型的区别是什么？

4

2 回答 2

1

只要您不将语义附加到名称，您就可以执行第二个操作。不幸x:author的是，在第二种情况下似乎具有误导性，因为我们通常不会将审稿人视为作者。

您最初声明的目标“包含与同一类型资源的多个语义不同的关系”可以通过使用两种链接关系类型然后在返回的表示中使用元数据来通知客户端这两种表示是同一类型来实现。我不确定是否有一种干净的方法可以将目标类型嵌入到上下文文档中。这通常不是一种对 HTTP 非常友好的处理方式。

于 2019-02-19T14:51:01.197 回答
1

即使您认为这两个人是“作者”，但他们与主要资源的关系并不是“作者”。

链接关系类型应该描述的不是“链接资源是什么类型的资源”，而是“链接资源与上下文资源有什么关系”。

于 2019-02-19T15:29:42.233 回答