Question

我是一个尝试设计我的第一个REST API架构的REST noob。

考虑使用简单的REST API来列出/查看/编辑/删除用户对象。我们可以使用以下2种URL模式进行路由：

/users          # GET returns a list of users, POST allows creation of new user
/users/{userid} # GET returns user info, PUT for updating user info, DELETE to delete user

到目前为止，这么好。现在让我们假设用户可以安排在可嵌套的文件夹中。因此，用户现在可以位于文件夹中，文件夹可以包含用户和子文件夹。为了允许管理文件夹，我们希望在API中添加以下功能：

列出文件夹的内容（用户和子文件夹）
创建新文件夹
重命名，删除文件夹
将用户或子文件夹移至其他父文件夹

在REST API中提供此功能的最佳方法是什么？我提出了两个想法：

构思1：在网址中显示文件夹层次结构

e.g。 /users/folder1/folder2/chris

乍一看，这看起来很不错，但这种方法存在许多问题：

用户和文件夹现在都具有相同的网址格式。无法知道/users/a/b/c是指向用户还是文件夹。这使得难以理解的API，以及涉及手动解析URL和猜测的恼人实现。
当客户端向POST发送/users/folder1时，我们不知道他们是要创建新用户还是新子文件夹。他们必须在请求正文中指定。这又导致了令人烦恼的服务器端实现，并且似乎不是非常RESTful。
没有明显的方法允许资源从一个文件夹移动到另一个文件夹

提示2：将父文件夹信息添加到资源

保留上面显示的简单2网址格式，并向用户资源添加parentFolder字段。

e.g。 GET到/users可能会返回（以JSON格式）：

{'users': 
   [{'name':'chris','DoB':'1/1/1900','parentFolder':'/folder1/folder2'},
   ...]
}

添加单独的网址格式/folders和/folders/{folderid}，以便查看/修改/删除文件夹。

这解决了Idea 1的一些问题，但在设计方面让我感到不安：

添加资源的父级作为资源的属性似乎很奇怪。
为什么我们必须将用户及其文件夹分成不同的API，即使它们显然是相互关联的？

感谢您阅读此内容。他们有更好的方法来解决这个问题吗？

Answer 1

添加指向用户资源的链接以识别包含文件夹绝对没有什么奇怪之处。 RESTful设计95％用于添加资源之间的链接，5％用于决定URI的外观。

使用用户资源或文件夹资源对/ users / a / b / c执行POST不应引起您的担忧。执行RESTful HTTP的一个主要优点是您不受RPC限制的约束。我们习惯于静态定义输入参数和输出参数的过程调用。 HTTP具有Content-Type之类的标题字段，允许在运行时定义输入和输出参数。

我相信你是正确的，选项＃2可能比选项＃1更容易在服务器上发送。但是，只要您通过使用服务器返回客户端可能需要的所有链接来避免客户端上的URI构造，任何一个选项对您的客户端都应该没问题。

移动用户可以像将用户张贴到新文件夹一样简单，让服务器弄清楚是否需要从旧文件夹中删除用户。

Answer 2

我正在思考同样的问题。

目前，我倾向于http响应Content-Type标头application / octet-stream vs application / json，如果有效负载是数据vs文件夹资源，则通知客户端，并允许正确解释有效负载。

管理文件夹层次结构中的资源有什么好的REST实践？

2 个答案: