当用户注册我的网络应用程序时，我会发送一封电子邮件来验证他的收件箱。 在电子邮件中有一个指向这样的资源的链接：
GET /verify/{token}
既然资源是在后台更新的，是不是破坏了 RESTful 方式？
如何以 RESTful 方式进行操作？
【问题讨论】：
标签： rest email-validation
您所说的不是 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。
【讨论】：
这取决于你想做什么。
它会在验证用户后触发电子邮件吗？如果是这样，它不是幂等方法，您应该使用 POST。
例子：
POST /users/{id}/verify/{token}
如果该方法除了更新没有任何后果，我认为你应该使用PUT。
【讨论】：
你是不是想太多 REST 了？通过电子邮件验证，您希望用户能够简单地单击他正在使用的任何邮件用户代理的链接，因此您最终会在服务器上得到一个简单的 GET（以超链接的形式呈现给用户）标记在路径中或作为查询字符串的一部分：
GET http://example.com/verify-email/TOKEN
GET http://example.com/verify-email?token=TOKEN
对于这个用例来说，两者都可以。它实际上并不是您正在获取或创建的资源；只是后端某些进程的触发器。
为什么你认为这会违反好的设计？
【讨论】：