REST 和 HATEOAS：属性中的链接

Question

我目前正在开发一个 API，它试图通过在 API 响应中包含指向相关资源的链接来做一点 HATEOAS。

在某些地方，我 (ab?) 将链接用于文章图片之类的内容。因此，例如文章资源可能如下所示：

{
  "type": "article",
  "id": "1",
  "links": {
    "self": "/api/articles/1",
    "image": "/files/b4d7802c-9cbb-4b65-9181-28cb547d2796"
  },
  "attributes": {
    "title": "My first blog entry",
    "slug": "first",
    "created_at": "2016-08-01T00:00:00Z"
  }
}

如您所见，我已将文章图片的链接添加到 links 哈希中。当时的想法是：这是一个 URL，所以它可能应该去那里。但是，也可以认为文章图片是文章的一个属性。

所以，我的问题： REST 社区中是否有任何公认的准则来处理如何判断 URL 是超媒体链接还是属性？这两种方法的优点/缺点是什么？

Answer 1

REST 社区中是否有任何公认的准则来处理如何判断 URL 是超媒体链接还是属性？

如果 URL 出现在由表示的媒体类型定义的链接元素中，那么它就是超媒体链接。

如有疑问，请查看您的参考实现：万维网。 HTML 文件中的 URL 何时是链接？ A元素、区域元素、链接元素；这一切都在spec 中。与 p 元素中间格式正确的 URL 的产生规则匹配的字符序列？不是链接。

这是菲尔丁在2008 中所说的话

REST API 应该将几乎所有的描述性工作都用于定义用于表示资源和驱动应用程序状态的媒体类型，或定义扩展关系名称和/或现有标准媒体的超文本启用标记类型。

换句话说，您应该使用一种超媒体格式，其中链接和属性之间的差异被明确指定。

现在，假设您有一个明确指定了区别的表示，您应该使用哪个？答案是您应该以适合您的用例的任何组合来使用它们。

创建链接对于任何预期宣传与其他可识别资源的关系的表示都有意义。也就是说，正如您可能猜到的那样，这是网络上非常常见的情况，通常在使用 HATEOAS 时也是如此。

我认为 URL 作为状态有意义的用例主要是您正在编辑某些内容的情况 - 如果我要加载我的个人资料的表示以便我可以更改我的主页，那么该表示是可能包含我以前的主页作为状态？

当然，人们可能同样认为它属于更新配置文件链接关系——再次，人们应该检查他们的假设与“你将如何在网页中做这件事？”启发式。