Question

对于我正在开发的REST API，客户端可以注册公司，随后需要通过电子邮件进行确认/激活。收到以下示例请求后，将发送一封电子邮件，其中包含激活链接，以激活该帐户。

<customer_group translate="label">
    <label>Customer Group</label>
    <frontend_type>multiselect</frontend_type>
    <source_model>adminhtml/system_config_source_customer_group</source_model>
    <sort_order>30</sort_order>
    <show_in_default>1</show_in_default>
    <show_in_website>1</show_in_website>
    <show_in_store>1</show_in_store>
    <comment><![CDATA[Specific customer group selection.]]></comment>
</customer_group>

如果上述请求成功（有效数据，电子邮件已成功发送），公司资源将保存在数据库中，但只有在收到确认后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>

是一个更恰当的回应？

Answer 1

REST是一个基于实体的概念。如果我得到201 Created响应，这将直观地表明资源已经创建并且可用，这不是这种情况。确认后资源首先可用，因此我建议使用202 Accepted标头。

此外，您无法确定用户是否在请求时收到了电子邮件。我喜欢在这些情况下使用202 Accepted（短信，电子邮件等），因为它告诉API消费者它是一个有效的请求，但它可能需要一些时间才能完成。

Answer 2

我的想法是：

201 - 当所有的东西/处理在请求结束时完成（DB填充，文件创建等），所以当客户端（事件立即）获取资源时，他将完成它。

202 - 当收到请求并成功开始处理时，但根据流程的某些限制，没有处理所有与请求相关的活动。

在你的情况下：

如果同步发送电子邮件并且在发送电子邮件之前没有回复，那么我猜201（已创建）就可以了

例如，如果您将电子邮件发送任务放入队列并立即返回客户端，稍后可能会发送电子邮件（或者例如，在发送电子邮件之前，操作员会对新客户端进行一些手动处理），而202则更好。

当资源等待电子邮件确认/激活时，202接受是否合适？

2 个答案: