对于我正在开发的REST API，客户端能够注册公司，随后需要通过电子邮件进行确认/激活。在收到以下示例请求后，将发送一封包含激活链接的电子邮件，以激活该帐户。
POST /companies HTTP/1.1
<company>
<name>CoolCompany</name>
<email>coolcompany@example.com</email>
</company>
如果上述请求成功(有效数据，电子邮件已成功发送)，则公司资源将保存在数据库中，但在收到确认后，仅在/companies/<id>(给定适当的授权标头)可用。
在这种情况下，是
HTTP/1.1 202 Accepted
// Perhaps optionally with a Location header,
// of where the resource will be available, as well?
Location: /companies/<id>
适当的回应?还是
HTTP/1.1 201 Created
Location: /companies/<id>
是一个更合适的回应吗?
REST是一个基于实体的概念。如果我得到201 Created响应，这将直观地表明资源已被创建并且可用，但本例并非如此。在确认之后，资源首先可用，因此我建议使用202 Accepted标头。
此外，您不能确定用户在请求时是否收到了电子邮件。我喜欢在这样的情况下使用202 Accepted(短信，电子邮件等)，因为它告诉API消费者这是一个有效的请求，但它可能需要一些时间才能完成。
我的想法是:
201 -当所有的东西/处理在请求结束时完成(DB填充，文件创建等)，所以当客户端(事件立即)获取资源时，他将收到它完成。
202 -收到请求并成功开始处理，但根据进程的一些限制，没有处理所有与请求相关的活动。
在你的情况下:
如果同步发送电子邮件并且在电子邮件发送之前不返回响应，那么我猜201(创建)是OK的
如果你将邮件发送任务设置为队列，并立即返回到客户端，并且邮件可能稍后发送(或者例如，在发送电子邮件之前，操作员对新客户端进行了一些手动处理)，那么202更好。