image - 休息 api 设计和工作流程上传图像。

Question

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

策略一:

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

优点:易于实现

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

策略2:

向 /api/pictures/ 发送一个 post 请求，为图像变体创建必要的信息并将其存储在数据库中，然后返回一个 202 accepted，并开始创建实际的图像变体文件，202 响应包含一个带有新 url 的位置 header ，类似于 /api/pictures/:pictureId/status 到“monitor”图像变体创建过程的状态。客户端可以使用此 url 检查进程是否已完成，如果进程已完成，则返回 201 created，如果进程未决，则返回 200 ok，如果在此过程中出现错误，它将结束并返回一个 410 gone

优点:客户端会得到非常快的响应，而不必等到所有图像变体都创建完毕。

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

策略三:

这与策略 2 非常相似，但它不是返回整个“进程”的位置，而是返回一个位置数组，其中包含每个图像变体的状态 url，这样客户端可以检查每个图像变体的状态而不是整个过程的状态。

优点:与策略 2 相同，如果一个图像变体在创建过程中失败，其他变体不受影响。例如，如果其中一个变体在创建过程中失败，它会返回 410 gone，而正确创建的图像会返回 201 created。

缺点:客户端很难实现，因为它必须跟踪一组位置而不是仅仅一个位置，请求的数量与变体的数量成正比。

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

Answer 1

您真正的问题是如何处理 HTTP 中的异步请求。我解决这个问题的方法通常是采用选项 2，返回 202 Accepted 并允许客户端使用 Location URI 上的 GET 检查当前状态如果他愿意的话。

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