设计RESTful API以将资源作为目录和文件进行管理[关闭]-Java 学习之路

我正在设计一个RESTful API，用于处理（以及其他）管理目录和文件 .
由于一些棘手的业务规则（如下所列），我在寻找良好的资源结构和良好的URI设计方面遇到了一些麻烦......

有很多目录 .
目录有很多文件 .
只能从其父目录访问文件列表 .
可以访问特定文件"globally"（仅限其ID）
可以创建文件，但客户端不能指定父文件夹（因为新文件保存在特殊目录中，只能在以后移动等）

这是一个可能的URI设计：

获取所有目录：
GET / api /目录

获取属性目录：
GET / api / directories /

获取目录中的文件：
GET / api / directories / / files

获取文件：
GET / api / files /

删除文件：
DELETE / api / files /

创建一个文件：
POST / api /文件

这是一个尴尬的设计吗？如果是，为什么？
另外，如果要记录这个RESTful API，这也有点尴尬：

Directories resource
资源URI：
/ API /目录

可能的操作：

GET / api /目录
GET / api / directories /

其他资源的链接：
（？）如何写这个？有一个指向 Files 资源的链接，但只有在使用第二个操作时才能访问该链接 .

Files resource
资源URI：
（？）...有两个URI ...一个用于"get all"（"or get many"），另一个用于其余操作 .

可能的操作：

GET / api / directories / / files
GET / api / files /
DELETE / api / files /
POST / api / files

其他资源的链接：
链接到 Directory 资源 - 请注意这里的单数（？）
严格来说，没有 Directory 资源，但是有一个 Directories 资源 - 我应该分别处理这两个（目录VS目录）吗？请在最后看到问题 . 此外，此链接仅在前两个操作中可用...如何在指定时更精确？

此外，我已经看到一些RESTful API文档具有 collection -like资源和 instance / element -like资源的单独条目（例如，请参阅this） .
这样的粒度文档是否更可取？我想一个优点是文档的"Links to other resources"（或"related resources"）部分会更精确 . 还是我错了？

任何想法都表示赞赏！
谢谢：）

1 回答

1
我不会说你拥有的东西特别尴尬 . 如果是我，我会支持这些网址：
```
GET /directories

GET /directories/{directoryId}    // includes a link to the files in the directory, such as /files?directoryId={directoryId}
GET /directories/{directoryId}?expand=files    // includes a child collection with links to each individual file resource, and possibly other metadata as well

GET /files
GET /files?directoryId={directoryId}
POST /files

GET /files/{fileId}
DELETE /files/{fileId}
```
/directories/{directoryId}/files 范式很常见，但不是我的最爱 . 如果用户想要目录的文件，他们可以使用 /files 上的查询参数 . 如果他们希望文件与目录同时存在，则可以在 /directories/{directoryId} 上使用查询参数 .

当然，这都是主观的 . 在不知道所有具体细节的情况下，没有人能够为您提供规范正确的答案 .

就文档而言，就像你拥有的一样，改变它以避免尴尬 . 此外，您有多个目录实例 . 从 /directories/{directoryId} 返回的每个资源都是一个目录 .
回复于 2024-04-27T21:39:38+08:00

设计RESTful API以将资源作为目录和文件进行管理[关闭]

1 回答

相关问题