我已经制作了REST API已有一段时间了，但我仍然遇到一种情况-大文件上传。我已经阅读了其他一些API，例如Google Drive，Twitter和其他文献，但我有两个想法，但是我不确定它们中的任何一个是否正确。适当地说，我的意思是它有些标准化，不需要太多的客户端逻辑（因为其他方将实现该客户端），或者甚至更好，可以使用cURL轻松调用它。计划是用Java（最好是Play Framework）实现它。
显然，由于文件很大，因此我需要一些文件分区和服务器端缓冲机制。
因此，我得到的第一个解决方案是分段上传（multipart/form-data）。我采用这种方式，并且之前已经实现过这种方式，但是在客户端实际模拟表单对于我来说总是很奇怪，尤其是因为客户端必须设置文件密钥名称，而根据我的经验，这就是客户有点忘记或不理解。另外，块大小/部分大小是如何规定的？是什么使客户端无法将整个文件放在一个块中？
解决方案二，至少是我所了解的，但是没有找到实际的实现实现，是“常规” POST请求可以工作。内容应分块，数据应在服务器端进行缓冲。但是，我不确定这是否是正确的理解。数据实际上是如何分块的，上载是跨多个HTTP请求还是在TCP级别分块？什么是Content-Type？
最重要的是，这两种（或其他什么？）中的什么应该是一种客户端友好的，可广泛理解的实现用于文件上传的REST API的方法？
我建议您看一下Amazon S3 Rest API的分段文件上传解决方案。该文档可在此处找到。
总结Amazon使用的过程：
客户端发送请求以启动分段上传，API会以上传ID进行响应
客户端上载每个文件块的零件号（以保持文件的顺序），零件的大小，零件的md5哈希和上传ID；这些请求中的每一个都是一个单独的HTTP请求。API通过对照客户端提供的md5哈希值检查接收到的md5哈希数据块来验证该数据块，并且该数据块的大小与客户端提供的大小相匹配。该API会以该块的标签（唯一ID）作为响应。如果您在多个位置部署API，则需要考虑如何存储块，然后以透明的方式访问它们。
客户端发出一个完成上传的请求，其中包含每个块编号的列表以及从API接收到的相关块标记（唯一ID）。API会验证没有丢失的块，并且块编号与正确的块标记匹配，然后组合文件或返回错误响应。
Amazon还提供了中止上传并列出与上传相关联的块的方法。您可能还需要考虑上载请求的超时，如果在一定时间内未完成上载，则这些块将被破坏。
在控制客户端上载的块大小方面，您对客户端决定拆分上载的方式没有太大的控制权。您可以考虑为上传配置最大块大小，并为包含大于最大大小的块的请求提供错误响应。
我发现该过程非常适合处理REST API中的大文件上传，并简化了与文件上传相关的许多极端情况的处理。不幸的是，我还没有找到一个可以轻松实现任何语言的库，因此您几乎必须自己编写所有逻辑。
本文收集自互联网，转载请注明来源。
如有侵权，请联系 [email protected] 删除。
我来说两句