具有通知的端点的REST API设计

Question

我正在创建一个API端点，它接收客户订单，创建订单并发送电子邮件通知。在我们当前的设计中，一旦我们成功创建订单，我们就会向客户发送成功通知201，然后拨打我们的内部电子邮件API。收到成功通知后，客户端应用会向用户显示一条消息，以检查他/她的电子邮件。

我对此设计感到不舒服，因为如果由于某种原因电子邮件发送方法失败，客户端无法理解这一点。另一方面，如果我们等待成功发送电子邮件然后发送客户端应用程序成功通知，则需要更长时间。

那么克服这个问题的正确方法是什么？

Answer 1

我认为你的设计有效。如果邮件服务不起作用，客户为什么要关心？如果订单在服务器上通过所有验证并且持久存在，我会将其视为成功状态并返回201 Created。

当客户获得201 Created时，那就按照你说的去做;向用户提供有关检查邮件的消息，但告诉他们应该有耐心。类似的东西：

  

您的订单已提交。请检查你的邮件。如果您在24小时内没有收到邮件，请联系我们，“或其他任何解决方案”。

您无法控制邮件到达用户邮箱的时间，因为邮件发送不是同步过程。

请记住：分开你的遗体。

Answer 2

对于需要进一步处理的请求，

202 Accepted通常是最合适的响应。但是，在您的情况下，这可能不正确，因为电子邮件不是资源创建的基础。

201 Created完全可以接受，因为订单实际上已经创建了。但是，正如规范所述，应返回Location标头，其中包含已创建资源的URI以及描述如何访问资源的实体。这应该解决你的邮件服务失败的问题 - 客户仍然可以访问他们的订单，说实话，电子邮件不保证交付，所以我希望电子邮件不是绝对必需的部分业务流程。