Question

我试图理解在使用关联类型和具有Name属性的链接之间的细微差别。

也许一个例子可以最好地说明我的问题。考虑一个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"}
      ]
    }
  }

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

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

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

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

我做了一些搜索，但没有找到任何使用链接的name属性的示例。我很乐意看到一些，和/或希望听听作者关于该领域的意图。

更新。

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

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

Answer 1

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

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

Answer 2

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

链接关系类型不应该描述“链接资源是哪种资源”，而是“链接资源与上下文资源之间的关系”。

HAL关系类型（相对）与链接名称属性

2 个答案: