【发布时间】：2015-03-26 17:27:21
【问题描述】：
我想设计一个允许客户端上传图像的 api，然后应用程序创建图像的不同变体，例如调整大小或更改图像格式，最后应用程序将每个变体的图像信息存储在数据库中。当我尝试确定执行此任务的正确策略时会出现问题，这里有一些我能想到的不同策略。
策略一：
向/api/pictures/发送post请求，
创建所有图像变体并返回201 created，如果所有图像文件都已正确创建并且图像信息已保存到数据库中，否则返回500 error。
优点：易于实施
缺点：客户端必须等待很长时间才能创建图像的所有变体。
策略 2：
向/api/pictures/发送一个post请求，只为图像变体创建必要的信息并将其存储在数据库中，然后返回一个202 accepted，并开始创建实际的图像变体文件，202响应包括带有新 url 的位置标头，例如 /api/pictures/:pictureId/status 以“监控”图像变体创建过程的状态。客户端可以使用这个url来检查进程是否完成，如果进程完成返回一个201 created，如果进程正在等待返回一个200 ok，如果过程中有错误，则结束并返回410 gone
优点：客户端会得到非常快的响应，而且它不必等到所有图像变体都创建完毕。
缺点：难以实现服务器端逻辑，客户端必须不断检查返回的位置 url 才能知道进程何时完成。
另一个问题是，例如当图像变体创建正确但一个失败时，整个过程返回一个410 gone，客户端可以继续向状态url发送请求，因为应用程序会尝试再次创建失败的图像，返回201 正确结束时。
策略 3：
这与策略 2 非常相似，但它不是为整个“过程”返回一个位置，而是返回一个位置数组，其中包含每个图像变体的状态 url，这样客户端可以检查每个单独图像变体的状态而不是整个过程的状态。
优点：与策略 2 相同，如果一个图像变体在创建过程中失败，其他变体不受影响。例如，如果其中一个变体在创建过程中失败，它会返回 410 gone，而正确创建的图像会返回 201 created。
缺点：客户端难以实现，因为它必须跟踪一组位置，而不仅仅是一个位置，请求的数量与变体的数量成正比。
我的问题是完成这项任务的最佳方法是什么？
【问题讨论】：
-
无论哪种方式，您都必须编写策略 1 的所有代码。当然，架构上存在一些差异。但是，如果您使策略 1 起作用，您可以尽早将其拿出并进行测试。您可能很快就会发现策略 1 在负载下太慢而无法实施。在这种情况下，您可以将精力转移到异步策略上。如果策略 1 可行，您可以同时提供同步和异步服务选项。