文件上传的 REST 设计 [英] REST design for file uploads

查看:29
本文介绍了文件上传的 REST 设计的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

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

  1. 打开会话
  2. 上传一堆文件
  3. 关闭会话

然后,回来处理他们在上一个会话中上传的文件.

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

/sessions//会话/3/会话/3/文件/会话/3/文件/5/sessions/3/file/5/content/sessions/3/file/5/metadata

这将允许文件元数据与文件内容分开处理.在这种情况下,文件内容和文件元数据只允许使用GET,并且要更新其中一个,必须PUT一个新文件.

这有意义吗?如果没有,为什么以及如何更好?

解决方案

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

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

<前><代码># 返回根目录的所有文件和子目录GET/{userId}/filesGET/{userId}/files/file1GET/{userId}/files/dir1# 创建或更新文件PUT/{userId}/files/file2

上传文件内容时,您将使用多部分内容类型.

评论后修改答案

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

表示上传"资源:

<前><代码>{"上传内容" : "http://storage.org/2a34cafa" ,元数据":{ .... }"}

资源操作:

<前><代码>#上传文件资源发布/文件-> HTTP 201 创建-> 目标位置由 HTTP 标头 'Location:/files/2a34cafa 显示#/uploads 作为命名感觉比/files 更自然一些POST/sessions/{sessionId}/uploads-> HTTP 201 创建-> HTTP 标头:'位置:/sessions/{sessionId}/uploads/1-> 还返回有效载荷# 更新上传(如元数据)/PUT/sessions/{sessionId}/uploads/1

I want to create a REST API for a file upload service that allows a user to:

  1. Open a session
  2. Upload a bunch of files
  3. Close the session

And then later, come back and do things with the files they uploaded in a previous session.

To facilitate dealing with data about each file and dealing with the content of the file itself, this is the URI scheme I am thinking of using:

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

This will allow the file metadata to be dealt with separately from the file content. In this case, only a GET is allowed on the file content and file metadata, and to update either one, a new file has to be PUT.

Does this make sense? If not, why and how could it be better?

解决方案

Why do you need sessions? Is it for Authentication and Authorization reasons? If so I would use http basic with SSL or digest. As such there is no start or end session, because http is stateless and security headers are sent on each request.

Suggestion of upload resource would be to directly map as private filesystem


# 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



When uploading file content you then would use multipart content type.

Revised answer after comment

I would design your wanted separation of file-content and payload by introducing link (to file-content) inside upload payload. It eases resource structure.

Representation 'upload' resource:


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

Resource actions:


# 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 


这篇关于文件上传的 REST 设计的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆