本文介绍了资源等待电子邮件确认/激活时,"202接受"是否适当?的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

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

For a REST API I'm developing, a client is able to register a company, which subsequently needs confirmation/activation through email. After the following example request is received, an email is sent with an activation link in it, to activate the account.

POST /companies HTTP/1.1

<company>
  <name>CoolCompany</name>
  <email>[email protected]</email>
</company>

如果以上请求成功(有效数据,电子邮件已成功发送),则公司资源将保存在数据库中,但仅在收到确认后才能在/companies/<id>(具有适当的Authorization标头)使用.

If the above request was successful (valid data, email successfully sent), the company resource is saved in the database, but will only be available at /companies/<id> (given an appropriate Authorization header) after confirmation is received.

鉴于这种情况,

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标头.

REST is an entity based consept. If I got a 201 Created response, this would intuitively suggest that the resource has been created and is available, which is not this case. The resource is first available after the confirmation, and I would therefore suggest using the 202 Accepted header.

此外,您不能确保用户在请求时已收到电子邮件.我喜欢在这种情况下(SMS,电子邮件等)使用202 Accepted,因为它告诉API使用者这是一个有效的请求,但可能要花一些时间才能完成.

In addition, you can not be sure that the user has received the email at the request time. I like using 202 Accepted in cases like these (SMS, Email etc), because it tells the API consumer that it was a valid request, but it might take some time before it is done.

这篇关于资源等待电子邮件确认/激活时,"202接受"是否适当?的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持!

07-24 11:32