REST：孩子和家长

Question

之间语境采取以下URI的为例：

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

我有一个关于最后一个问题，URI（/播放/：ID /曲目）。如何将额外信息/上下文添加到与其父播放列表相关的跟踪对象？上下文

例子：

1. 上架时间的轨道到播放列表中曲目的播放列表中
2. 游戏计数每磁道
3. 喜欢的播放列表中

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

我已经想出了以下现在：

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

我添加了一个域名为relation_to_parent它增加了一些方面对孩子之间的关系，它的父。我不确定如果这是一个好办法。希望听到其他解决方案。

Answer 1

如果您想完全接受RESTful服务设计原则，您一定希望在您的表示格式中使用超链接。 JSON有一些现有的规格，如果你不想拿出自己的：HAL和JSON API。一个天真的超媒体格式可能是这样的：

{ 
    "playlist_id" : "666", 
    "created_at" : "2014-11-07 19:21:64", 
    "likes" : 5, 
    "tracks" : [ 
     {"index" : 1, 
     "begin_at" : "00:02:00", 
     "end_at" : "00:05:23", 
     "_links" : {"track" : { 
      "href" : "/tracks/123", 
      "type" : "track"}}}, 
     {"index" : 2, 
     "_links" : {"track" : { 
      "href" : "/tracks/432", 
      "type" : "track"}}}, 
     {"index" : 3, 
     "_links" : {"track" : { 
      "href" : "/tracks/324", 
      "type" : "track"}}}, 
     {"index" : 4, 
     "_links" : {"track" : { 
      "href" : "/tracks/567", 
      "type" : "track"}}}] 
} 

更复杂的功能都包含在这两个HAL和JSON API，就像定义嵌入的资源和链接样板。使用这样的语义，你可能会像下面这样结束：

{ 
    "id" : "666", 
    "created_at" : "2014-11-07 19:21:64", 
    "likes" : 5, 
    "tracks" : [ 
     {"id" : "123", 
     "index" : 1, 
     "begin_at" : "00:02:00", 
     "end_at" : "00:05:23"}, 
     {"id" : "432", 
     "index" : 2}, 
     {"id" : "324", 
     "index" : 3}, 
     {"id" : "567", 
     "index" : 4} 
    ], 
    "_links" : { 
     "_self" : { 
      "href" : "/playlists/666", 
      "type" : "playlist"}, 
     "tracks" : { 
      "href" : "/tracks/{id}", 
      "type" : "track"} 
    }, 
    "_embedded" : { 
     "track" : [ 
      {"id" : "123", 
      "title" : "harder better faster stronger", 
      "artist" : "daft punk", 
      "created_at" : "2012-10-03 09:57:04", 
      "likes" : 234252, 
      "play_count" : 1203200035}, 
      {"id" : "432", 
      "title" : "aerodynamic", 
      "artist" : "daft punk", 
      "created_at" : "2009-03-07 11:11:11", 
      "likes" : 33056, 
      "play_count" : 8796539} 
     ] 
    } 
} 

另外，不要忘了使用超链接来表示实体之间的静态关系是旅程才刚刚开始。使用Hypermedia As The Engine Of Application State是真正的涅ana ......但是那时你可能会瞄准太高。

Answer 2

我不认为有这样做的“一个真正的方法”。就我个人而言，我不喜欢添加这样的额外信息，因为当您正在寻找资源时，您正在提供资源加。无论如何，“喜欢”，“created_at”和“play_count”实际上是与父母关系的一部分，是不是它们本身的一部分？

这两个路径我经常看到这样的：

1. /playlist/:id/tracks - 返回ID（或URL）的实际的曲目列表，然后您可以用/tracks/:track
2. /playlist/:id/tracks取 - 返回实际的轨道，就好像你在上面的1中一样。

至于更多的信息，如果不是轨道的一部分，你可能会做它（任何这些是有效的）：

• 信息作为轨道的一部分，所以/tracks/:track总是返回'play_count'和'likes'等
• 单独的信息，即它自己的资源，如果你想保持轨道干净。所以，你可能会在/tracks/:track/social_info得到它也许/social_info/:track它的轨道ID 1对1

如果你有实际关系信息相匹配，那就要看它是否是1：1或1：N或N： 1或N：N。 1：1或1：N或N：1，您可能会将其报告为资源本身的一部分，而N：N可能是资源的一部分（JSON对象可能具有深度）或作为单独的资源。

就个人而言，我已经完成了上述所有内容，并且发现清洁更好，即使是多次检索。但是，现在我们深入研究的意见....

编辑：

有很多方法可以做到N：N，下面就介绍几种：

• /playlist/:id/tracks/:track/social_info - 它可以嵌入或另一个对象
• /social_info/:playlist链接 - 更直接
• /social_info/playlist/:id如果你可能有不同的社会信息的

个人（再次有这个词;这很大程度上是个人偏好和意见），每时间我已经尝试过使用更深的路径，思考的东西只有在父上下文有意义，我发现自己结束了自己的资源，并链接回来，所以第二个或第三个选项最终成为我所做的事情，首先链接到它（方便地检索它或检索它的列表）。大多数情况下，这并不是因为服务器端的限制 - 例如，当我使用nodejs编写代码时，我使用http://github.com/deitch/booster，它很容易处理到同一资源的多条路径 - 但由于客户端框架通常在一条真实路径上运行得更好。

Answer 3

通过1：n关系你可以定义一个子资源。通过n：m关系，最好定义一个单独的关系资源。请注意，这些只是最佳做法，而不是标准。

请注意，您可以添加指向其他资源的链接。根据HATEOAS约束，如果要公开某个操作（例如获取其他资源），则必须创建超链接。