REST：子级和父级之间的上下文

以以下URI为例：

/tracks
/tracks/:id
/playlists
/playlists/:id
/playlists/:id/tracks

我有一个关于最后一个URI（/playlists/：id/tracks）的问题。如何向与父播放列表相关的曲目对象添加额外信息/上下文

上下文示例：

将曲目的时间添加到播放列表中

播放列表中曲目的播放计数

播放列表中每首曲目的喜欢度

在全球范围内，所有曲目都有一个创建的时间戳、播放次数等。所以我的问题是如何将这些信息添加到端点的响应中

目前，我提出了以下建议：

{
    "title" : "harder better faster stronger",
    "artist" : "daft punk",
    "likes" : 234252,
    "created_at" : "2012-10-03 09:57:04"
    "play_count" : 1203200035,
    "relation_to_parent": {
        "likes" : 5,
        "created_at" : "2014-11-07 19:21:64",
        "play_count" : 20
    }
} 

---

我已经添加了一个名为relationship\u to\u parent的字段，它为子对象与其父对象之间的关系添加了一些上下文。但我不确定这是否是一个好方法。希望听到一些其他的解决方案

如果您想要完全接受RESTful服务设计原则，那么您肯定希望在表示格式中使用超链接。如果您不想提出自己的规范，JSON有一些现有规范：和。简单的超媒体格式可能如下所示：

{
“播放列表id”：“666”，
“创建时间”：“2014-11-07 19:21:64”，
“喜欢”：5，
“轨道”：[
{“索引”：1，
“开始时间”：“00:02:00”，
“结束时间”：“00:05:23”，
“_链接”：{“跟踪”：{
“href”：“/曲目/123”，
“类型”：“跟踪”}}，
{“索引”：2，
“_链接”：{“跟踪”：{
“href”：“/曲目/432”，
“类型”：“跟踪”}}，
{“索引”：3，
“_链接”：{“跟踪”：{
“href”：“/曲目/324”，
“类型”：“跟踪”}}，
{“索引”：4，
“_链接”：{“跟踪”：{
“href”：“/曲目/567”，
“类型”：“轨迹”}}]
}

HAL和JSON API中都包含了更详细的功能，比如定义嵌入式资源和链接模板。使用这种语义，您可能会得到如下结果：

{
“id”：“666”，
“创建时间”：“2014-11-07 19:21:64”，
“喜欢”：5，
“轨道”：[
{“id”：“123”，
"索引":1,，
“开始时间”：“00:02:00”，
“结束时间”：“00:05:23”}，
{“id”：“432”，
“索引”：2}，
{“id”：“324”，
“索引”：3}，
{“id”：“567”，
“索引”：4}
],
“_链接”：{
“_self”：{
“href”：“/播放列表/666”，
“类型”：“播放列表”}，
“轨道”：{
“href”：“/tracks/{id}”，
“类型”：“轨道”}
},
“_嵌入式”：{
“轨道”：[
{“id”：“123”，
“标题”：“越硬越好，越快越强”，
“艺术家”：“愚蠢的朋克”，
“创建时间”：“2012-10-03 09:57:04”，
“喜欢”：23425，
“播放计数”：120320035}，
{“id”：“432”，
“标题”：“空气动力学”，
“艺术家”：“愚蠢的朋克”，
“创建时间”：“2009-03-07 11:11:11”，
“喜欢”：33056，
“播放计数”：8796539}
]
}
}

---

另外，不要忘记，使用超链接来表示实体之间的静态关系只是旅程的开始。使用是真正的涅盘。。。但是你的目标可能太高了。

我认为没有一种“真正的方法”可以做到这一点。就我个人而言，我不喜欢添加这样的额外信息，因为当你在寻找资源时，你是在提供资源加号。在任何情况下，“likes”和“created_at”以及“play_count”实际上是与父项的关系的一部分吗？它们不是

轨道本身的一部分吗

我通常看到的两条路径是：

/playlist/：id/tracks
-返回实际曲目的id（或URL）列表，然后使用
/tracks/：track
/playlist/：id/tracks
-返回实际曲目，就像您执行了上面1中的两个步骤一样
至于其他信息，如果它不是曲目的一部分，您可以这样做（其中任何一个都是有效的）：


信息作为曲目的一部分，因此
/tracks/：track
始终返回“播放次数”和“喜欢”等
如果您希望保持轨道清洁，请提供单独的信息，即其自身的资源。因此，您可以在
/tracks/：track/social\u info
或
/social\u info/：track
中找到它，它与曲目ID 1对1匹配

如果您有实际的关系信息，那么这取决于它是1:1还是1:N或N:1还是N:N。1:1或1:N或N:1您可能会报告为资源本身的一部分，而N:N可能是资源的一部分（JSON对象可以具有深度）或作为单独的资源

就我个人而言，我已经完成了上述所有工作，并且发现cleaner更好，即使是多次检索。但现在我们正在深入探讨意见

编辑：

有很多方法可以做N:N，这里只是一些：


/playlist/：id/tracks/：track/social_info
-可以嵌入或链接到其他对象
/social\u info/：播放列表
-更直接
/social\u info/playlist/：id
如果您可能有不同类型的社交信息

就我个人而言（这个词又出现了；这很大程度上是个人偏好和观点），每当我尝试使用更深层次的途径，认为某些东西只有在父母的背景下才有意义时，我发现自己最终为它创造了自己的资源，并链接回来，所以第二个或第三个选择就是我所做的，第一次链接到它（方便检索它或检索它的列表）

大多数情况下，这并不是因为服务器端的限制（例如，当我在nodejs中编写时，我使用nodejs非常容易地处理同一资源的多条路径），而是因为客户端框架通常使用一条真正的路径工作得更好。
通过1:n关系，您可以定义子资源