文件上传的 REST 设计 [关闭]

Posted 2023-02-19

【中文标题】文件上传的 REST 设计 [关闭]

【英文标题】：REST design for file uploads [closed]

【发布时间】：2012-01-16 04:45:50

【问题描述】：

我想为文件上传服务创建一个 REST API，允许用户：

打开一个会话 上传一堆文件 关闭会话

然后，再回来处理他们在上一个会话中上传的文件。

为了方便处理有关每个文件的数据和处理文件本身的内容，这是我正在考虑使用的 URI 方案：

/sessions/
/sessions/3
/sessions/3/files
/sessions/3/files/5
/sessions/3/file/5/content
/sessions/3/file/5/metadata

这将允许文件元数据与文件内容分开处理。在这种情况下，只允许对文件 content 和文件 metadata 进行 GET，并且要更新其中任何一个，都必须 PUT 一个新文件。

这有意义吗？如果不是，为什么以及如何更好？

【问题讨论】：

您可以查看许多流行的公共 REST API，以获取有关如何处理文件上传的灵感。我个人更熟悉 Google Drive API developers.google.com/drive/v2/reference/files/insert 或（更新的）Dropbox API dropbox.com/developers/reference/api 还有很多其他的......

Dropbox：body 是文件，URL 上的元数据? 参数。

dropbox 的做法很愚蠢，为什么要把 HTTP 动词放在 Uri 中。它在 Http 标头中指定。这是多余的，只是愚蠢的

这是为了保证对老客户的支持。有些客户可以只做 POST 和 GET。不过我喜欢你的简历：>“[...] 谁愿意在有礼貌的耐心庄园中学徒、分享和​​学习。”

【参考方案1】：

为什么需要会话？是出于身份验证和授权的原因吗？如果是这样，我会使用带有 SSL 的 http basic 或 digest。因此没有开始或结束会话，因为 http 是无状态的，并且每个请求都会发送安全标头。

上传资源的建议是直接映射为私有文件系统

# returns all files and subdirs of root dir GET /userId/files GET /userId/files/file1 GET /userId/files/dir1 # create or update file PUT /userId/files/file2

上传文件内容时，您将使用multipart content type。

评论后修改答案

我会通过在上传负载中引入链接（到文件内容）来设计您想要的文件内容和负载分离。它简化了资源结构。

表示“上传”资源：

"upload-content" : "http://storage.org/2a34cafa" , "metadata" : " .... "

资源操作：

# upload file resource POST /files -> HTTP 201 CREATED -> target location is shown by HTTP header 'Location: /files/2a34cafa # /uploads as naming feels a bit more natural as /files POST /sessions/sessionId/uploads -> HTTP 201 CREATED -> HTTP header: 'Location: /sessions/sessionId/uploads/1 -> also returning payload # Updating upload (like metadata) /PUT/sessions/sessionId/uploads/1

【讨论】：

会话与身份验证无关。它们仅用于将一批上传分组在一起。除了为每个会话输入的信息外，没有经典意义上的“用户”。也没有目录的概念（目前），但每个上传的文件都有大量的元数据。

啊，误会了...看看我更新的答案（最后一部分）。