如何为运行树状数据的RESTful服务构造URI？

问题描述

| 假设我有类似树的数据，例如“文件”和“文件夹”，基本操作是“列表文件夹”，“创建文件夹”，“重命名”，“创建文件”，“获取文件”。 那么如何为RESTful服务构造URI？我已经尝试了几次，但是所有解决方案对我来说都不是很好。 例如，如果我有URI`http://example.com/rest/here_path_to_folder引用的“文件夹”资源，如何列出文件夹项目？从此文件夹中获取“文件”？ 我见过Amazon AWS文档，他们使用的不是很干净的方法-将“文件夹”路径和文件夹定界符作为查询参数，这可能会引起歧义，因为不同的URI将引用相同的资源。我也尝试将关键字附加到路径的末尾，因此列出“文件”看起来像：

GET /rest/path/to/folder:list HTTP/1.1

改名：

POST /rest/path/to/folder:rename?target=NEW_NAME HTTP/1.1

但这对我来说仍然很糟糕。那么，您是否知道在分层数据上使用100％REST的成功案例？     

解决方法

我认为使用URI表示分层数据结构应该非常简单。尽管URI并不严格表示层次结构（某些人喜欢保持层次结构，然后变得完全不透明），但有意义的URI确实具有自然的层次结构感，因此应很好地映射到您的文件/文件夹示例。 在RESTful系统中，资源具有一个公共接口，该接口（在您的情况下）由HTTP动词定义。 URI标识资源，REST指示不应将其用于指示您尝试执行的操作。 所以代替

GET /rest/path/to/folder:list HTTP/1.1

我建议您仅使用以下命令列出文件夹的内容（查找其状态）：

GET /rest/path/to/folder HTTP/1.1

这应该返回代表该文件夹包含的文件和子文件夹的URI列表。然后，要获取其中一个文件的内容，我可能会调用：

GET /rest/path/to/folder/myfile HTTP/1.1

重命名有点棘手。在某些情况下，先按

DELETE

再按

PUT

即可，但是我猜您想保留文件夹内容而不必重新上传。一个选项是

PUT

，其中主体包含一个新的文件夹路径，该路径以204响应，并且Location头值指向新创建的文件夹（如此处的“重命名标签”中所述）。可选：如果您希望对用户真正友好，如果有人向旧URI发出请求，则还可以返回301状态（永久移动），并带有指向新URI的链接。 请记住，路径只是构成文件夹状态的属性之一，您可以使用

PUT

更新该状态，而无需引入自定义\'rename \'操作。在您的情况下，您碰巧使用了路径来确定URI，但是对于状态更改导致URI更改而言，它是完全有效的。