Question

我正在考虑如何确认电子邮件和请求重置密码的最佳RESTful方式。我只是想找到正确的URI ......

确认电子邮件

PUT /users/{userId}/confirmEmail?code=xyz - 由于confirmEmail

，似乎没有多少RESTful

PUT /users/{userId}/email?confirmedBy=xyz - 也许更好？说不上

重置密码（类似问题）

PUT /users/{userId}/resetPassword --DATA {email:xyz@xyz.xy} - 和以前一样思考

PUT /users/{userId}/password --DATA {state:reseted,resent:xyz@xyz.xy} - 嗯...再次我不确定

你有什么更好的方法吗？： - ）

Answer 1

如果您希望URI引用资源，请将资源confirmation和POST确认调用到用户帐户。

POST /users/{userid}/confirmation

Answer 2

真正的RESTful答案是URL无关紧要，无论如何都要将其放入确认电子邮件中，以便收件人遵循。使用对您的负载均衡器，反向代理，服务器等最方便的任何内容。

为了方便起见，即使它出现在GET请求中，你也最终会接受确认，因为这就是人们对Roy T. Fielding博士等人遗忘的肉体和骨头的浏览器。点击电子邮件中的链接时发送： - ）

建立它是完全学术性的，我认为你考虑PUT是正确的，因为客户有意识地提供了访问电子邮件的证据。重复请求没有进一步的效果。

Answer 3

这是一种RESTful方式。

请求

PUT /{userid}/email HTTP/1.1 Content-Type: text/json+confirmation-code {"activateCode": "23sfgsg3twt3rgsdhgs"}

<强>响应

HTTP/1.1 200 OK Content-Type: text/json+email-status {"email": "my-email@address.com", "active": "true"}

URI中没有动词：）

Answer 4

考虑到他为忘记密码的人说了重置服务，而不是已经登录的人更改密码服务......

我会使用2项服务。第一个请求重置密码邮件，第二个用接收邮件中收到的令牌设置新密码。

对于第一个：
POST baseUrl / passwordReset
请求正文

{
   "email" : "my@self.com"
}

这可能是POST或PUT，但由于邮件传递不是CRUD的资源，所以不要迂腐并使用html表单中常用的旧POST。

显然我会控制同一个客户端（ip？浏览器？...）不会让我在一分钟内发送20K邮件。

将邮件发送给用户并不意味着旧密码无效。只有当新的请求更新它时，才会在第二个请求中发生。

响应204（即使您不知道该电子邮件，也许您应该这样做，因为如果您返回错误，这意味着当您没有返回错误时，您正在向陌生人确认给定的电子邮件已注册）< / p>

第二名：
POST baseUrl /密码
请求正文

{
    "token" : "3D21BA...4F",
    "newPassword" : "m%4pW1!O"
}

邮件中收到令牌的地方。因此，邮件可以包含指向包含令牌的页面的链接，当页面加载时，表单被填充并提交，作为一个隐藏字段，一些javascript从URL读取并放在这里。

这实际上是您更新的资源，因此POST。而且我认为为两者设置2个动词的URI是不合理的，因为它们根本不是同一个资源/实体。

添加的顺便说一句，我只会同时使用HTTPS，这就是为什么我将所有敏感信息放在正文中，而不是URL参数。

Answer 5

首先，我不认为PUT是正确的方法。 PUT广义上意味着“把它放在这里”，其中URL标识内容应该位于何处。您真的要求现有资源执行某些操作，这使POST更正确。

要回答您的直接问题，RESTful URL应标识您要处理请求的资源。在这种情况下，资源是用户或用户中的某些密码重置资源。

我的偏好是密码重设资源：

POST /users/{userid}/password-reset

从HTTP的角度来看，这是有道理的，因为您可以在资源上发出GET并接收指示如何操作密码重置的内容（例如，提示输入相关联的电子邮件地址的HTML表单帐户）。

修改

出于电子邮件验证的目的，有两个明显的选择。您可以使用电子邮件地址和确认数据POST到“确认电子邮件”资源，要求服务器处理确认，或者您可以执行PUT将确认信息放在服务器上：

POST /users/{userid}/confirm-email

或

PUT /users/{userid}/email-confirmation

Answer 6

我没有看到像第一个例子那样使用confirmEmail有什么问题。在URL中，您拥有用户的密钥，confirmEmail是操作，具有该操作的数据位于查询字符串中。

Answer 7

我最近在研究过这个问题，我的看法是

POST /{base_url}/password

因为我实际上是在创建一个新的随机密码并将其发送给用户

和

PUT /{base_url}/confirmation?token=...

因为我正在更新用户注册时已发出的确认信息。

RESTful重置密码并确认电子邮件

7 个答案: