相关疑难解决方法(0)

我需要为文件上传服务创建一个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.

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

有没有上传超过2 GB的文件,使用简单的html表单上传？以前我一直在使用分块通过silverlight上传大文件(将一个大文件分成多个段然后逐个上传段然后在服务器上重新组合段).

现在,我们要求我们只需要使用简单的html(尽管是GWT)表单上传.如果有任何方法可以通过这种方式实现大文件上传,请指导我.

如果使用简单的html无法做到这一点,那么有人可以指导我如何使用flex分段和上传文件吗？

我试图权衡设置Content-LengthHTTP标头与使用分块编码从我的服务器返回[可能]大文件的优缺点.需要使用持久连接来满足HTTP 1.1规范中的一个或另一个.我看到Content-Length标题的优点是:

• 下载对话框可以显示准确的进度条
• 如果文件可能/可能不太大而无法摄取,则客户端会提前知道

缺点是必须在返回对象之前计算大小,这并不总是实用并且可能会增加服务器/数据库利用率.分块编码的缺点是在每个块和下载进度条之前添加块大小的开销很小.有什么想法吗？我可能没有想到的两种方法的任何其他HTTP注意事项？