rest - HAL 关系类型 (rel) 与链接名称属性

Question

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

也许一个例子最能说明我的问题。考虑代表同行评审文章的 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 spec 的阅读和 Web Linking spec ，上述方法既有效又与许多示例一致。

但是...如果我按如下格式设置相同的响应会怎样:

  {
    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"}
      ]
    }
  }

在此示例中，我选择使用关系类型来指示资源类型，并遵循链接的名称属性来缩小关系含义。

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

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

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

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

---

更新..

到目前为止的回复都强调关系类型旨在反射(reflect)上下文和 href 处的结果之间的关系，而不是该目的地的资源类型。

这是可以理解的，但如果可能的话，请详细说明链接名称属性的用途。将其与关系类型区分开来的使用示例是什么？

Answer 1

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

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