REST API-文件（即图像）处理-最佳实践

Question

我们正在用REST API开发服务器，它用JSON接受和响应。问题是，如果您需要将图像从客户端上传到服务器。

注意：我也在讨论一个用例，其中实体（用户）可以有多个文件(carPhoto，licensePhoto)，也可以有其他属性(name，email……)，但是当您创建新用户时，您不会发送这些图像，它们是在注册过程之后添加的。

我知道这些解决方案，但每一个都有缺陷

1.使用multipart/form-data而不是JSON

好：POST和PUT请求是尽可能RESTful的，它们可以包含文本输入和文件。

缺点：它不再是JSON，与多部分/表单数据相比，它更容易测试、调试等

2.允许更新单独文件

创建新用户的POST请求不允许添加图像（这在我们的用例中是可以的，如我开头所说的），上传图片是通过PUT请求作为多部分/表单数据来完成的，例如/users/4/Carphoto

很好：所有的东西（除了文件上传本身）都保留在JSON中，很容易测试和调试（您可以记录完整的JSON请求而不用担心它们的长度）

缺点：它不直观，您不能一次发布或放入实体的所有变量，而且这个地址/users/4/Carphoto可以更多地视为一个集合（REST API的标准用例类似于以下内容/users/4/shipments)。通常您不能（也不想）获取/放置实体的每个变量，例如users/4/name。您可以在users/4上用get获取name并用PUT更改它。如果id后面有内容，通常是另一个集合，如users/4/reviews

3.使用Base64

将其作为JSON发送，但使用base64对文件进行编码。

好：和第一个解决方案一样，它是尽可能的RESTful服务。

缺点：再一次，测试和调试是非常糟糕的（主体可能有兆字节的数据），在客户机和服务器中都增加了大小和处理时间

我真的想用解决方案No。2,但它也有它的缺点...谁能给我一个更好的洞察力“什么是最好的”解决方案？

我的目标是拥有包含尽可能多标准的RESTful服务，同时我希望保持它尽可能简单。

Answer 1

OP这里（我是在两年后回答这个问题的，Daniel Cerecedo发表的文章一次还不错，但是web服务发展非常快）

经过三年的全职软件开发（同时也专注于软件架构、项目管理和微服务架构），我肯定会选择第二种方式（但有一个通用的endpoint）作为最好的方式。

如果您有一个特殊的图像endpoint，它将使您在处理这些图像时拥有更大的能力。

我们对两者都有相同的REST API（node.js）--移动应用（iOS/Android）和前端（使用React）。这是2017年，因此你不想在本地存储图像，你想把它们上传到一些云存储（Google cloud、s3、cloudinary、……)，因此你想要对它们进行一些通用的处理。

我们的典型流程是，只要您选择了一个图像，它就开始在后台上传（通常在/imagesendpoint上发布），上传后返回ID。这是真正的用户友好，因为用户选择一个图像，然后通常继续一些其他字段（即地址，姓名，...)，因此当他点击“发送”按钮，图像通常已经上传。他不会等着看屏幕上写着“上传...”。

获取图像也是如此。特别是由于手机和有限的移动数据，你不想发送原始图像，你想发送调整大小的图像，所以它们不占用那么多带宽（而且为了让你的移动应用更快，你通常根本不想调整它的大小，你想要的图像完全适合你的视图）。由于这个原因，好的应用程序使用cloudinary之类的东西（或者我们有自己的图像服务器来调整大小）。

此外，如果数据不是私有的，那么您只向app/frontend发送URL，它就会直接从云存储下载，这将为服务器节省大量的带宽和处理时间。在我们较大的应用程序中，每个月都有很多TB的下载量，您不希望在每个REST API服务器上直接处理这些，因为REST API服务器专注于CRUD操作。您希望在一个地方处理它（我们的Imageserver，它有缓存等），或者让云服务处理它的全部。

缺点：您应该想到的唯一“缺点”是“未分配图像”。用户选择图像并继续填充其他字段，但他说“不”并关闭应用程序或标签，但同时你成功上传了图像。这意味着您上载了一个没有分配到任何地方的图像。

有几种处理方法。最简单的一个是“我不关心”，这是一个相关的，如果这种情况不是经常发生，或者您甚至希望存储用户发送给您的每一个图像（出于任何原因），并且您不希望任何删除。

另一种方法也很简单--每周都有CRON和IE,并且删除所有未分配的早于一周的映像。