RESTdevisefile upload

我需要为file upload服务创build一个REST API，允许用户：

1. 打开一个会话
2. 上传一堆文件
3. closures会话

然后，再回来做一些上一个会话中上传的文件。

为了便于处理关于每个文件的数据并处理文件本身的内容，这就是我正在考虑使用的URIscheme：

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

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

这有道理吗？ 如果不是的话，为什么，怎么会更好？

Answer 1

为什么你需要会议？ 是否出于身份validation和授权的原因？ 如果是这样的话，我会用SSL 基本或摘要 。 因此，没有开始或结束会话，因为http是无状态的，每个请求都会发送安全性头文件。

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

# 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

# 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 

上传文件内容时，您将使用多部分内容types 。

修改后的评论回答

我会通过在上传有效负载中引入链接（到文件内容）来devise你想分离的文件内容和有效载荷。 它缓解了资源结构。

表示“上传”资源：

{ "upload-content" : "http://storage.org/2a34cafa" , "metadata" : "{ .... }" }
{ "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
# 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