我需要为文件上传服务创建一个REST API,允许用户:
然后,回过头来处理他们在之前会话中上传的文件。
为了便于处理有关每个文件的数据并处理文件本身的内容,这是我正在考虑使用的URI方案:
/sessions/
/sessions/3
/sessions/3/files
/sessions/3/files/5
/sessions/3/file/5/content
/sessions/3/file/5/metadata
这将允许从文件内容中单独处理文件元数据。在这种情况下,文件 content 和文件元数据上只允许GET,并且要更新任何一个,新文件必须是PUT。
这有意义吗?如果没有,为什么以及如何更好?
答案 0 :(得分:15)
为什么需要课程?它是出于身份验证和授权的原因吗?如果是这样,我会将http basic与SSL或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