java rest 图_REST API - 文件（即图像）处理 - 最佳实践

OP here (两年后我回答这个问题，Daniel Cerecedo的帖子一次都不错，但网络服务发展很快)

After three years of fulltime software development (重点关注软件架构，项目管理和微服务架构)我绝对选择第二种方式(但有一个通用 endpoints )作为最佳方式 .

如果您有特殊的图像 endpoints ，它可以为您处理图像提供更多功能 .

我们有两个相同的REST API(Node.js) - 移动应用程序(iOS / android)和前端(使用React) . 这是2017年，因此你不想存储图像localy，你想上传它们来 Cloud 存储(谷歌 Cloud ，s3，cloudinary，...)，因此你想要一些一般处理它们 .

我们的典型流程是，只要您选择图像，它就会开始在背景上上传(通常是POST在/ images endpoints 上)，上传后会返回ID . 这实际上是用户友好的，因为用户选择图像然后通常继续其他一些字段(即地址，名称......)，因此当他点击“发送”按钮时，图像通常已经上传 . 他不等着看着屏幕说“上传......” .

获取图像也是如此 . 特别是由于移动电话和有限的移动数据，你不想发送原始图像，你想发送调整大小的图像，所以他们不会采取那么多的数据(并使你的移动应用程序更快，你通常不想调整它的大小，你想要的图像完全适合你的视图) . 出于这个原因，好的应用程序正在使用像cloudinary这样的东西(或者我们有自己的图像服务器用于调整大小) .

此外，如果数据不是私有的，那么您只需将URL发送回app / frontend，就可以直接从 Cloud 存储中下载，这样可以大大节省带宽和服务器的处理时间 . 在我们更大的应用程序中，每个月都会下载很多太字节，您不希望直接在每个REST API服务器上处理它，这些服务器专注于CRUD操作 . 您希望在一个地方(我们的Imageserver，它有缓存等)处理它，或让 Cloud 服务处理所有这些 .

缺点：您应该想到的唯一“缺点”是“未分配图像” . 用户选择图像并继续填写其他字段，但随后他说“不”并关闭应用程序或选项卡，但同时您成功上传了图像 . 这意味着您已上传未在任何地方分配的图像 .

有几种方法可以解决这个问题 . 最简单的是“我不在乎”，这是相关的，如果这种情况不经常发生，或者你甚至希望存储用户发送给你的每一个图像(出于任何原因)，你不想要任何删除 .

另一个也很容易 - 你有CRON，即每周都删除所有未分配的图像超过一周 .