树结构的REST URI设计

Question

有很多关于REST URI设计的讨论,但没有一个回答我的问题.

假设我有一些包含任务和/或其他列表的列表(list = node和task = leaf).

我们可以有类似的东西

/lists/{id_list1}/lists/{id_list2}/lists/{id_list3}/tasks/{id_task1} 

或者更简短的版本:

/lists/{id_list1}/{id_list2}/{id_list3}/{id_task1}

但真正的深树呢？

我也在考虑可以翻译的父/子关系

/lists/{id_list_parent}/{id_list_or_task_child} 

但我觉得有些东西不见了......

什么是REST URI树的智能设计？

编辑

对不起,我迟到了!

所以我认为我混合了两个需求:API URI和浏览器URI.

这是我看到的东西:

在API方面,我只有那些写入和读取方法的URI(例如,对于创建而言,不需要末尾的'/ id'):

/lists/id
/tasks/id

然而,在我的浏览器上,我会有这样的事情:

/lists/id/lists/id/tasks/

服务器只会解释第一部分(/ lists/id),我的客户端javascript将使用第二部分(lists/id/tasks /)来查找从服务器接收的列表子列表的任务.

你怎么看待这种方法,它有什么不妥之处吗？

Answer 1

是否需要通过URI表示树？当它们可以简单地引用节点本身时,关系通过超媒体类型中的链接建模.

除此之外,我认为如下:

/lists/{nodeId}/children

它可以将直接子项列表返回给父项.

你也可以这样做:

/lists/{nodeId}/children?depth=3

并在结果中返回树的下三个级别.

/lists/{nodeId}/children?depth=infinite

可以从该节点返回整个分支.

Answer 2

使用 URI 来强制执行此约束似乎不正确。我会接受具有某种有效负载（JSON、XML 等）的 PUT 请求。

PUT /tasklist

lists: [{
   id: 1234,
   id: 12345,
   tasks: [{
      id: foo,
      id: bar,
      id: baz
   }]
}]

该 URL 似乎表明您试图在这里做太多事情（恕我直言）。通常，您将与单个资源进行交互，而您的用例意味着您同时对多个上下文分层的资源进行操作。