我想设计一个API，允许客户端上传图像，然后应用程序创建图像的不同变体，例如调整大小或更改图像格式，最后应用程序将每个变体的图像信息存储在数据库中。当我尝试确定执行此任务的正确策略时，就会出现问题，以下是我能想到的一些不同策略。
策略一：
发送帖子请求至/api/pictures/,
创建所有图像变体并返回201 created如果所有图像文件都正确创建并且图像信息已保存到数据库中，否则返回500 error.
pros:易于实施
cons:客户端必须等待很长时间才能创建图像的所有变体。
策略2：
发送帖子请求至/api/pictures/，仅创建图像变体所需的信息并将其存储在数据库中，然后返回202 accepted，并开始创建实际的图像变体文件，202响应包含一个带有新 url 的位置标头，例如/api/pictures/:pictureId/status“监视”图像变体创建过程的状态。客户端可以使用这个url来检查进程是否完成，如果进程完成返回一个201 created，如果进程处于挂起状态，则返回200 ok，如果过程中出现错误，则结束并返回410 gone
pros:客户端可以获得非常快的响应，并且不必等到创建所有图像变体。
cons:很难实现服务器端逻辑，客户端必须不断检查返回的位置 url，才能知道进程何时完成。
另一个问题是，例如，当正确创建图像变体但失败时，整个过程会返回一个410 gone，客户端可以继续向状态 URL 发送请求，因为应用程序将尝试再次创建失败的图像，并返回201当它正确结束时。
策略3：
这与策略 2 非常相似，但它不是返回整个“流程”的位置，而是返回一个位置数组，其中包含每个图像变体的状态 url，这样客户端就可以检查每个图像变体的状态，而不是检查每个图像变体的状态。整个过程的状态。
pros:与策略2相同，如果一个图像变体在创建过程中失败，其他变体不受影响。例如，如果其中一个变体在创建过程中失败，它将返回410 gone而正确创建的图像会返回201 created.
cons:客户端很难实现，因为它必须跟踪一系列位置而不仅仅是一个位置，请求数量与变体数量成比例增加。
我的问题是完成这项任务的最佳方法是什么？
