REST设计用于文件上传

Question

我想创建一个REST API，为文件上传服务提供支持，用户可以：

1. 开启会话
2. 上传多个文件
3. 关闭会话

然后，稍后回来并对以前会话中上传的文件进行操作。

为了方便处理每个文件的数据和内容，我考虑使用以下URI方案：

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

这将允许文件元数据与文件内容分开处理。在这种情况下，仅允许对文件的内容和文件的元数据进行GET操作，并且要更新其中任何一个，都必须使用PUT上传一个新文件。

这样说清楚了吗？如果有什么不明白的地方，为什么？如何让它更好理解？

- cdeszaq

---

有许多受欢迎的公共REST API可供参考，以了解如何处理文件上传。我个人更熟悉Google Drive API https://developers.google.com/drive/v2/reference/files/insert或（更新）Dropbox API https://www.dropbox.com/developers/reference/api。当然还有许多其他API可供选择… - Ferenc Mihaly

Dropbox：文件主体是文件，元数据在URL ? 参数上。 - Ciro Santilli OurBigBook.com

Dropbox的做法很愚蠢，为什么要把HTTP动词放在URI中？它已经在HTTP头中指定了。这是多余的，只是愚蠢的。 - PositiveGuy

这是为了确保对旧客户的支持。有些客户只能使用POST和GET方式。我很喜欢你的个人简介: "[...] 愿意在礼貌耐心的态度下，拜师学习并与他人分享和学习。" - Erem

Answer 1

为什么需要会话？是为了身份验证和授权的原因吗？如果是这样，我建议使用带有SSL或摘要的http basic。因此，没有开始或结束会话，因为HTTP是无状态的，安全头在每个请求中发送。

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

# 返回根目录下的所有文件和子目录
GET /{userId}/files
GET /{userId}/files/file1
GET /{userId}/files/dir1
# 创建或更新文件
PUT /{userId}/files/file2

上传文件内容时，您应该使用多部分内容类型。

评论后修订的答案

我建议通过在上传负载中引入链接（到文件内容）来设计所需的文件内容和负载分离。它可以简化资源结构。

表示“上传”资源：

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

资源操作：

# 上传文件资源
POST /files
-> HTTP 201 CREATED 
-> 目标位置在HTTP头'Location: /files/2a34cafa'中显示
# /uploads命名更自然，因此可以用来代替/files
POST /sessions/{sessionId}/uploads
-> HTTP 201 CREATED
-> HTTP头：'Location: /sessions/{sessionId}/uploads/1'
-> 同时返回有效载荷
# 更新上传（例如元数据）
/PUT/sessions/{sessionId}/uploads/1 

- manuel aldana

---

会话与身份验证完全无关。它们仅用于将一批上传分组在一起。除了为每个会话输入的信息之外，没有经典意义上的“用户”。目前也没有目录的概念，但是与每个上传文件相关联的元数据非常多。 - cdeszaq

啊，误解了...看看我的更新答案（最后一节）。 - manuel aldana