JSON 表示形式中的链接关系

发布于 2024-11-28 12:05:13 字数 1706 浏览 1 评论 0原文

我正在设计一个基于 JSON 表示的 RESTful API。为了遵守 HATEOAS,我广泛使用资源之间的链接。因此,我遵循此建议以与 ATOM 非常相似的方式序列化链接链接。

现在,我有时在识别正确的链接关系类型时遇到问题。当资源包含指向其自身的链接时,self 关系就很明显。当资源是子资源的集合和聚合,或者包含许多相关资源的链接时,它会变得更加复杂。

以一篇博客文章为例,考虑一个返回博客文章快照的资源——包括该博客文章的作者、标签和评论。 显然,该资源包含许多子资源,当然还应该提供指向它们的单独链接:

示例资源:

{
   "blogpost":{
      "link":{
         "rel":"self",
         "href":"http://blog/post/4711"
      },
      "author":{
         "name":"Bob",
         "link":{
            "rel":"???",
            "href":"http://author/uri"
         }
      },
      "title":"foobar",
      "content":"A long article here…",
      "comments":[
         {
            "comment":"great article",
            "link":{
               "rel":"???",
               "href":"http://blog/post/4711/comment/1"
            },
            "author":{
               "name":"John Doe",
               "link":{
                  "rel":"???",
                  "href":"http://author/uri"
               }
            }
         }
      ],
      "tags":[
         {
            "value":"foo",
            "link":{
               "rel":"???",
               "href":"http://blog/post/4711/tag/foo"
            }
         }
      ]
   }
}

那又怎样给定的链接是否有适当的关系?我知道存在诸如 tag 之类的关系类型,但并非所有资源都与现有关系类型匹配。或者在引用作者/标签/评论时使用 self 是否可以,因为它与封闭的 JSON(子)对象的上下文相关? self 所指的语义实体是什么?

RFC 5988 规定:

链接的上下文可以是提要 IRI 或条目 ID,具体取决于它出现的位置

如何用 JSON 来解释它?每个新对象 {…} 都是一个新上下文吗?

谢谢!

I'm designing a RESTful API based on JSON representations. In order to comply with HATEOAS, I use links between resources extensively. Therefore, I followed this suggestion for serializing links in way very similar to ATOM links.

Now I have sometimes problems identifying the correct link relation type. When a resource contains a link to itself, the self relation is obvious. It gets more complex when the resources are collections and aggregations of sub-resources, or contain many links to related resources.

Take a blog post as an example, and think of a resource that returns a snapshot of the blog post – including the author, tags and comments of this blog post.
Obviously, this resource contains many subresources and should of course also provides separate links to them:

Sample Resource:

{
   "blogpost":{
      "link":{
         "rel":"self",
         "href":"http://blog/post/4711"
      },
      "author":{
         "name":"Bob",
         "link":{
            "rel":"???",
            "href":"http://author/uri"
         }
      },
      "title":"foobar",
      "content":"A long article here…",
      "comments":[
         {
            "comment":"great article",
            "link":{
               "rel":"???",
               "href":"http://blog/post/4711/comment/1"
            },
            "author":{
               "name":"John Doe",
               "link":{
                  "rel":"???",
                  "href":"http://author/uri"
               }
            }
         }
      ],
      "tags":[
         {
            "value":"foo",
            "link":{
               "rel":"???",
               "href":"http://blog/post/4711/tag/foo"
            }
         }
      ]
   }
}

So what are appropriate relations for the given links? I know that there are relation types such as tag, but not all of my resources match the existing relation types. Or is it okay to use self when referring to the author/tag/comment, because it relates to the context of the enclosing JSON (sub-)object? What is the semantical entity self is referring to?

RFC 5988 states:

The context of the link is either a feed IRI or an entry ID, depending on where it appears

How can I interpret this in terms of JSON? Is each new object {…} a new context?

Thanks!

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(3

红墙和绿瓦 2024-12-05 12:05:13

这是一个很好的问题。如果您查看 Hal 的示例,您将看到 rel 是在子上下文中定义的资源。
我不知道有关 rel 何时与整个资源或包含的子资源相关的任何明确指南。
我可以向您指出的唯一额外信息是 RFC5988 中的锚参数,它允许您使用片段或全新的 URI 重新定义上下文 IRI。

理想情况下,您的媒体类型应说明嵌套资源的上下文 IRI 是否不同,或者上下文 IRI 是否需要显式更改。这将是使用像 application/vnd.hal+json 这样的媒体类型而不是像 Hal 规范所述的普通旧 application/json 的另一个优点:

@rel - 用于识别目标 URI 与“主题”的关系
资源”。主题资源是最接近的父资源
元素。

That is a great question. If you look at the example for Hal you will see that the rels are defined within the context of the sub-resource.
I do not know of any definitive guide on when the rel is related to the resource as a whole or a contained sub resource.
The only extra piece of information I can point you to is the anchor parameter in RFC5988 which allows you to redefine the context IRI using either a fragment or a completely new URI.

Ideally, your mediatype should state whether the context IRI is different for nested resources, or whether the context IRI needs to be explicitly changed. That would be another advantage of using a media type like application/vnd.hal+json instead of plain old application/json as the Hal spec states:

@rel - For identifying how the target URI relates to the 'Subject
Resource'. The Subject Resource is the closest parent Resource
element.

小红帽 2024-12-05 12:05:13

LSON-LD

您也许可以看看 JSON-LD链接数据。它看起来比 HAL但您可以用它做更多事情。JSON

-LD 正在 W3C 内部进行标准化,这里是 。

提案推荐

抱歉我没有时间提供示例..

LSON-LD

You can maybe have a look at JSON-LD (JavaScript Object Notation for Linked Data. It looks like more complicated than HAL but you can do more with it.

JSON-LD is being standardized inside of the W3C, here is the proposal recommendation.

Also

Sorry I don't have time to provide with an example..

执笔绘流年 2024-12-05 12:05:13

现在回答这个问题有点晚了,但为了将来的参考,这就是我解决这个问题的方法:

{
   "blogpost":{
      "title":"foobar",
      "content":"A long article here…",
      "link":{
         "rel":"self",
         "href":"http://blog/post/4711"
      },
      "link":{
         "rel": "author",
         "href": "http://author/uri",
         "alt":"Bob"
      },
      "link":{
        "rel": "comment",
        "alt": "great article",
        "href":"http://blog/post/4711/comment/1"
      },
      "link": {
        "rel":"tag",
        "href":"http://blog/post/4711/tag/foo",
        "alt":"foo"
      }
   }
}

当你想到它时,评论、标签等都是链接到你的帖子的不同资源......为什么不把它们全部变成什么他们是..链接!您甚至可以节省回复的大小;)

It's a bit late to answer that question but for future reference, this is how I solve this problem :

{
   "blogpost":{
      "title":"foobar",
      "content":"A long article here…",
      "link":{
         "rel":"self",
         "href":"http://blog/post/4711"
      },
      "link":{
         "rel": "author",
         "href": "http://author/uri",
         "alt":"Bob"
      },
      "link":{
        "rel": "comment",
        "alt": "great article",
        "href":"http://blog/post/4711/comment/1"
      },
      "link": {
        "rel":"tag",
        "href":"http://blog/post/4711/tag/foo",
        "alt":"foo"
      }
   }
}

when you think about it, comments, tags, etc are all distinct resources linked to your post ... why not then make them all what they are .. links ! You even save on the size of your response ;)

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文