REST API-文件(即图像)处理-最佳做法 [英] REST API - file (ie images) processing - best practices
问题描述
我们正在开发带有REST API的服务器，该服务器使用JSON进行接收和响应.问题是，如果您需要将图像从客户端上传到服务器.
注意:我也正在谈论一个用例，其中实体(用户)可以具有多个文件(carPhoto，licensePhoto)并且还具有其他属性(名称，电子邮件...)，但是当您创建新用户时，您不会发送这些图片，而是在注册过程后添加的.
我知道的解决方案，但是每个解决方案都有一些缺陷
1.使用multipart/form-data而不是JSON
好:POST和PUT请求尽可能地是RESTful，它们可以包含文本输入和文件.
cons :它不再是JSON，与multipart/form-data相比，它更易于测试，调试等.
2.允许更新单独的文件
创建新用户的POST请求不允许添加图片(在我的用例中，我一开始就这么说过)，通过PUT请求将图片作为多部分/表单数据上传到例如/users/4/carPhoto
好:所有内容(文件上传本身除外)均保留在JSON中，易于测试和调试(您可以记录完整的JSON请求而不必担心它们的长度)
cons :这不是直观的操作，您无法一次POST或PUT实体的所有变量，并且该地址/users/4/carPhoto可以更多地被视为一个集合(REST API的标准用例)看起来像这样/users/4/shipments).通常，您不能(也不想)获取/放置实体的每个变量，例如users/4/name.您可以使用GET获取名称，并使用users/4在PUT上更改名称.如果id后面有东西，通常是另一个集合，例如users/4/reviews
3.使用Base64
将其发送为JSON，但使用Base64编码文件.
好:与第一个解决方案相同，它是尽可能的RESTful服务.
cons :再次，测试和调试要差很多(主体可能具有兆字节的数据)，客户端和服务器的大小和处理时间都增加了
我真的很想使用解决方案编号. 2，但是它有缺点...任何人都可以让我对什么是最好的"解决方案有更好的了解?
我的目标是使RESTful服务包含尽可能多的标准，而我想使其尽可能简单.
此处操作(两年后，我正在回答这个问题，但丹尼尔·塞雷塞多(Daniel Cerecedo)发表的帖子一次也不错，但是网络服务发展很快)
经过三年的全职软件开发(也侧重于软件体系结构，项目管理和微服务体系结构)，我绝对选择第二种方法(但有一个通用端点)作为最佳方法
如果您有一个特殊的图像端点，则可以为您处理这些图像提供更多的功能.
我们对移动应用程序(iOS/android)和前端(使用React)都具有相同的REST API(Node.js).这是2017年，因此您不想在本地存储图像，而是要将它们上传到某些云存储(Google Cloud，s3，cloudinary等)，因此需要对其进行一些常规处理.
我们的典型流程是，一旦选择了图像，它就会开始在后台上传(通常是在/images端点上进行POST)，并在上传后返回ID.这确实是用户友好的，因为用户选择一个图像，然后通常继续进行其他一些字段(即地址，名称等)，因此，当他单击发送"按钮时，该图像通常已经上传.他不等待，看着屏幕上显示正在上传...".
获取图像也是如此.特别是由于手机和有限的移动数据，您不想发送原始图像，不想发送经过调整大小的图像，因此它们不会占用那么多的带宽(并且为了使您的移动应用程序更快，您通常不希望要完全调整它的大小，您需要图像完全适合您的视图).因此，好的应用程序正在使用诸如cloudinary之类的东西(或者我们有自己的图像服务器来调整大小).
此外，如果数据不是私有的，那么您仅将URL发送回应用程序/前端，然后直接从云存储中下载数据，这为服务器节省了大量带宽和处理时间.在我们较大的应用程序中，每个月下载的数据量为TB，您不想直接在专注于CRUD操作的每台REST API服务器上进行处理.您想在一个地方(我们的具有缓存等功能的Imageserver)处理该问题，或者让云服务处理所有这一切.
缺点:您应该想到的唯一缺点"是未分配的图像".用户选择图像并继续填写其他字段，但随后他说"nah"并关闭应用程序或选项卡，但与此同时，您成功上传了图像.这意味着您已上传未在任何地方分配的图像.
有几种处理方法.最简单的是我不在乎"，这是一个相关的问题，如果这种情况不是很经常发生，或者您甚至希望存储用户发送给您的每张图片(出于任何原因)并且您不想要任何图片删除.
另一种方法也很容易-您拥有CRON，即每周都有，并且删除了所有超过一周的未分配图像.
We are developing server with REST API, which accepts and responses with JSON. The problem is, if you need to upload images from client to server.
Note: and also I am talking about a use-case where the entity (user) can have multiple files (carPhoto, licensePhoto) and also have other properties (name, email...), but when you create new user, you don't send these images, they are added after the registration process.
The solutions I am aware of, but each of them have some flaws
1. Use multipart/form-data instead of JSON
good : POST and PUT requests are as RESTful as possible, they can contain text inputs together with file.
cons : It is not JSON anymore, which is much easier to test, debug etc. compare to multipart/form-data
2. Allow to update separate files
POST request for creating new user does not allow to add images (which is ok in our use-case how I said at beginning), uploading pictures is done by PUT request as multipart/form-data to for example /users/4/carPhoto
good : Everything (except the file uploading itself) remains in JSON, it is easy to test and debug (you can log complete JSON requests without being afraid of their length)
cons : It is not intuitive, you cant POST or PUT all variables of entity at once and also this address /users/4/carPhoto can be considered more as a collection (standard use-case for REST API looks like this /users/4/shipments). Usually you cant (and dont want to) GET/PUT each variable of entity, for example users/4/name . You can get name with GET and change it with PUT at users/4. If there is something after the id, it is usually another collection, like users/4/reviews
3. Use Base64
Send it as JSON but encode files with Base64.
good : Same as first solution, it is as RESTful service as possible.
cons : Once again, testing and debugging is a lot worse (the body can have megabytes of data), there is increase in size and also in processing time in both - client and server
I would really like to use solution no. 2, but it has its cons... Anyone can give me a better insight of "what is best" solution?
My goal is to have RESTful services with as much standards included as possible, while I want to keep it as simple as possible.
OP here (I am answering this question after two years, the post made by Daniel Cerecedo was not bad at a time, but the web services are developing very fast)
After three years of full-time software development (with focus also on software architecture, project management and microservice architecture) I definitely choose the second way (but with one general endpoint) as the best one.
If you have a special endpoint for images, it gives you much more power over handling those images.
We have the same REST API (Node.js) for both - mobile apps (iOS/android) and frontend (using React). This is 2017, therefore you don't want to store images locally, you want to upload them to some cloud storage (Google cloud, s3, cloudinary, ...), therefore you want some general handling over them.
Our typical flow is, that as soon as you select an image, it starts uploading on background (usually POST on /images endpoint), returning you the ID after uploading. This is really user-friendly, because user choose an image and then typically proceed with some other fields (i.e. address, name, ...), therefore when he hits "send" button, the image is usually already uploaded. He does not wait and watching the screen saying "uploading...".
The same goes for getting images. Especially thanks to mobile phones and limited mobile data, you don't want to send original images, you want to send resized images, so they do not take that much bandwidth (and to make your mobile apps faster, you often don't want to resize it at all, you want the image that fits perfectly into your view). For this reason, good apps are using something like cloudinary (or we do have our own image server for resizing).
Also, if the data are not private, then you send back to app/frontend just URL and it downloads it from cloud storage directly, which is huge saving of bandwidth and processing time for your server. In our bigger apps there are a lot of terabytes downloaded every month, you don't want to handle that directly on each of your REST API server, which is focused on CRUD operation. You want to handle that at one place (our Imageserver, which have caching etc.) or let cloud services handle all of it.
Cons : The only "cons" which you should think of is "not assigned images". User select images and continue with filling other fields, but then he says "nah" and turn off the app or tab, but meanwhile you successfully uploaded the image. This means you have uploaded an image which is not assigned anywhere.
There are several ways of handling this. The most easiest one is "I don't care", which is a relevant one, if this is not happening very often or you even have desire to store every image user send you (for any reason) and you don't want any deletion.
Another one is easy too - you have CRON and i.e. every week and you delete all unassigned images older than one week.
这篇关于REST API-文件(即图像)处理-最佳做法的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
