验证电子邮件的REST方式是什么？

Question

当用户注册我的Web应用程序时,我会发送一封电子邮件来验证他的收件箱.在电子邮件中有一个指向这样的资源的链接:

GET /verify/{token}

由于资源在幕后更新,它是否会破坏RESTful方法？

我怎么能以RESTful方式做到这一点？

Answer 1

你在谈论的不是REST.REST用于机器到机器的通信,而不用于人机交流.您可以开发第一方REST客户端,该客户端将激活发送到REST服务.

您可以在浏览器中使用验证URI来访问REST客户端:

# user follows a hyperlink in the browser manually

GET example.com/client/v1/verify/{token}
# asking the client to verify the token

然后,REST客户端将从REST服务获取用于验证的超链接,并在后台将POST发送到服务.

# the REST client follows the hyperlinks given by the service automatically
# the REST client can run either on the HTTP client or server side

GET example.com/api/v1
# getting the starting page of the REST service
# getting the hyperlink for verification

POST example.com/api/v1/verification {token}
# following the verification hyperlink

如果您有服务器端第一方REST客户端,那么对REST服务的HTTP请求将完全在服务器上运行,您将无法在浏览器中看到任何有关它的信息.如果您有客户端REST客户端,那么您可以使用AJAX CORS在浏览器中发送POST,或者您可以尝试使用HTML表单直接POST(不推荐).无论如何,激活应该是POST或PUT.

Answer 2

你是不是想太多了 REST？通过电子邮件验证，您希望用户能够简单地单击他正在使用的任何邮件用户代理中的链接，因此您最终会在服务器上获得一个简单的 GET（作为超链接呈现给用户），其中包含令牌位于路径中或作为查询字符串的一部分：

GET http://example.com/verify-email/TOKEN
GET http://example.com/verify-email?token=TOKEN

对于这个用例来说，两者都可以。它实际上并不是您正在获取或创建的资源；而是您正在获取或创建的资源。只是后端某些进程的触发器。

为什么你认为这会与良好的设计发生冲突？