11

有很多关于 REST URI 设计的讨论，但没有人准确回答我的问题。

假设我有一些包含任务和/或其他列表的列表（列表 = 节点和任务 = 叶）。

我们可以有类似的东西 

/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/）来查找从服务器接收到的列表的子列表的任务.

您如何看待这种方法，感觉有什么不对吗？

4

2 回答 2

12

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

除此之外，我认为是这样的：

/lists/{nodeId}/children

它可以将直接子代的列表返回给父代。

您还可以执行以下操作：

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

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

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

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

于 2012-05-29T22:04:20.320 回答
0

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

PUT /tasklist

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

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

于 2012-05-29T22:04:17.933 回答