注销：GET 还是 POST？

使用 POST。

在 2010 年，使用 GET 可能是一个可以接受的答案。但是今天（2013 年），浏览器会预取他们“认为”你接下来会访问的页面。

这是 StackOverflow 开发人员之一在 twitter 上谈论这个问题：

我要感谢我的银行注销 GET 请求，感谢 Chrome 团队提供方便的 URL 预取。- Nick Craver (@Nick_Craver) 2013 年 1 月 29 日

有趣的事实：StackOverflow 曾经通过 GET 处理注销，但现在不再这样了。

在 REST 中不应该有会话，因此没有什么可破坏的。 REST 客户端对每个请求进行身份验证。登录或退出，这只是一种错觉。

您真正要问的是浏览器是否应该继续在每个请求上发送身份验证信息。

可以说，如果您的应用程序确实产生了登录的错觉，那么您应该能够使用 javascript“注销”。无需往返。

菲尔丁论文 - Section 5.1.3

从客户端到服务器的每个请求都必须包含理解请求所需的所有信息，并且不能利用服务器上存储的任何上下文。因此，会话状态完全保留在客户端

此处可能滥用 GET 的一种方式是，某人（可能是竞争对手：）在 Internet 上放置了带有 src="<your logout link>" ANYWHERE 的图像标签，如果您网站的用户偶然发现该页面，他将在不知不觉中退出。

您好，在我看来，当您登录时检查用户名/密码，如果它们匹配，您将创建登录令牌。

CREAT 令牌 => 方法 POST

当您注销时，您会破坏令牌，所以对我来说最合乎逻辑的方法应该是 DELETE

DELETE 令牌 => 方法 DELETE

正确地说，GET/POST（或其他动词）是对某些资源（由 URL 寻址）的操作 - 所以它通常与资源的状态有关，而不是与应用程序状态本身有关。因此，实际上，您应该有一个诸如 [host name]\[user name]\session 之类的 URL，然后“删除”将是注销操作的正确动词。

以不是真正完整的 REST 方式 (IMO) 使用 [host name]\bla bla\logout 作为 URL，那么为什么要争论正确使用 GET/POST 呢？

当然，我也在我的应用程序中使用 GET 来注销 url :-)

注销对应用程序本身没有任何作用。它改变了用户与应用程序相关的状态。在这种情况下，您的问题似乎更多地基于用户应如何启动命令以开始此操作。由于这不是“破坏性操作”，因此请确保会话被放弃或销毁，但您的应用程序或您的数据都没有被更改，因此允许这两种方法启动注销过程并非不可行。该帖子应由任何用户发起的操作（例如 - 用户单击“注销”）使用，而 get 可以保留用于应用程序发起的注销（例如 - 检测到潜在用户入侵的异常会通过注销 GET 强行重定向到登录页面）。

预缓存的场景是一个有趣的场景。但我猜如果很多网站公司都不担心这一点，那么也许你也不应该担心。

或者也许链接可以用javascript实现？

编辑：据我了解，从技术上讲，GET 应该用于只读请求，不会更改应用程序状态。 POST 应该用于更改状态的写入/编辑请求。然而，对于一些状态变化的请求，其他应用程序问题可能更喜欢 GET 而不是 POST，我认为这没有任何问题。

好吧，如果您让您的 Web 应用程序通过注销脚本放弃会话，那么您通常也不需要。通常有一个会话变量对于您要放弃的会话是唯一的。

我看不出注销（取消提升用户权限）是一种破坏性行为。那是因为“注销”操作应该只对已经登录的用户可用，否则它将被过时。

您的浏览器 cookie 中包含的随机生成的字符串都代表您的用户会话。有很多方法可以销毁它，因此有效地注销只是为您的访问者提供的服务。