rest api设计和上传图片的工作流程。 [英] rest api design and workflow to upload images.

问题描述

我想设计一个允许客户端上传图像的API，然后应用程序创建不同的图像变体，如调整大小或更改图像格式，最后应用程序将每个变体的图像信息存储在数据库中。当我尝试确定实施此任务的正确策略时会出现问题，这里有一些我能想到的不同策略。

I want to design an api that allows clients to upload images, then the application creates different variants of the images, like resizing or changing the image format, finally the application stores the image information for each of the variants in a database. The problem occurs when I try to determine the proper strategy to implement this task, here are some different strategies i can think of.

发送帖子请求到 / api / pictures / ，
创建所有图像变体并返回 201创建如果所有图像文件都已正确创建并且图像信息已保存到数据库，否则返回 500错误。

Send a post request to /api/pictures/, create all the image variants and return 201 created if all image files were created correctly and the image information was saved to the database, otherwise it returns a 500 error.

优点易于实施

缺点：客户必须等待很长时间才能创建所有图像变体。

cons: the client has to wait a very long time until all variants of the images are created.

发送帖子请求到 / api / pictures / ，只为图像变体创建必要的信息并将其存储在数据库中，然后返回 202接受，并开始创建实际的图像变体文件， 202 响应包含一个带有新网址的位置标头，类似于 / api / pictures /：pictureId / status '监控'图像变体创建过程的状态。客户端可以使用此URL检查进程是否已完成，如果进程已完成，则返回 201创建的，如果进程处于挂起状态，则返回 200 ok ，如果在此过程中出现错误，则结束并返回 410消失

Send a post request to /api/pictures/, create just the necessary information for the image variants and store it in the database, then returns a 202 accepted, and start creating the actual image variant files, the 202 response includes a location header with a new url, something like /api/pictures/:pictureId/status to 'monitor' the state of the image variants creation process. The client could use this url to check whether the process was completed or not, if the process was completed return a 201 created, if the process is pending return a 200 ok, if there is an error during the process, it ends and returns a 410 gone

优点：客户端获得非常快速的响应，并且不必等到创建所有图像变体。

pros: the client gets a very fast response, and it doesn't have to wait until all image variants are created.

缺点：很难实现服务器端逻辑，客户端必须不断检查返回的位置url，以便知道进程何时完成。
另一个问题是，例如，当图像变体被正确创建但一个失败时，整个过程返回 410消失，客户端可以继续发送请求状态URL，因为应用程序将尝试再次创建失败的图像，正确结束时返回 201 。

cons: hard to implement server side logic, the client has to keep checking the returned location url in order to know when the process has finished. Another problem is that, for example when the image variants are created correctly but one fails, the entire process returns a 410 gone, the client can keep sending requests to the status url because the application will try to create the failed image again, returning a 201 when its end correctly.

这与策略2非常相似，但它不返回整个进程的位置，而是返回一个位置数组，每个位置都有状态URL图像变体，这样客户端可以检查每个单独图像变体的状态，而不是整个过程的状态。

This is very similar to strategy 2 but instead of return a location for the whole 'process', it returns an array of locations with status urls for each image variant, this way the client can check the status for each individual image variant instead of the status of the whole process.

优点：相同作为策略2，如果一个图像变体在创建期间失败，则其他变体不受影响。例如，如果其中一个变体在创建过程中失败，则会返回 410消失，而正确创建的图像将返回 201创建的。

pros: same as strategy 2, if one image variant fails during creation, the other variants are not affected. For example, if one of the variants fails during creation it returns a 410 gone while the images that were created properly returns a 201 created.

缺点：客户端很难实现，因为它必须跟踪一系列位置而不是一个位置，数量请求与变体数量成比例增加。

cons: the client is hard to implement because it has to keep track of an array of locations instead of just one location, the number of requests increases proportionally to the number of variants.

我的问题是完成此任务的最佳方法是什么？

My question is what is the best way to accomplish this task?

推荐答案

您真正的问题是如何处理HTTP中的异步请求。我解决这个问题的方法通常是采用选项2，返回 202 Accepted 并允许客户端使用 GET 如果他想要位置 URI。

Your real problem is how to deal with asynchronous requests in HTTP. My approach to that problem is usually to adopt option 2, returning 202 Accepted and allowing the client to check current status with GET on the Location URI if he wants to.

可选地，客户端可以在请求上提供回调URI标题，我将用它来通知完成。

Optionally, the client can provide a callback URI on a request header, which I will use to notify completion.

这篇关于rest api设计和上传图片的工作流程。的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！