休息 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/ 发送 post 请求，创建所有图像变体，如果所有图像文件创建正确且图像信息已保存到数据库，则返回201 created，否则返回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/ 发送一个 post 请求，只为图像变体创建必要的信息并将其存储在数据库中，然后返回一个 202 接受，并开始创建实际的图像变体文件，202 响应包括一个带有新 url 的位置标头，类似于 /api/pictures/:pictureId/status 到监视"图像变体创建过程的状态.客户端可以使用这个url来检查进程是否完成，如果进程完成返回201 created，如果进程挂起返回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 created.

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 并允许客户端使用 Location URI 上的 GET 检查当前状态如果他愿意.

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.

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