注销：GET还是POST？
这个问题不是关于什么时候使用GET或POST; 它是关于哪个是推荐的处理Web应用程序的注销。 从一般意义上，我发现GET和POST之间的区别很多，但是我没有find这个特定场景的明确答案。
作为一个实用主义者，我倾向于使用GET，因为实现它比POST更简单; 只需放下一个简单的链接，就完成了。 这似乎是我能想到的绝大多数网站的情况，至less从我的头顶来看。 即使堆栈溢出处理注销与GET。
让我犹豫的事情是，尽pipe有些networking加速器/代理通过检索页面中的每一个链接来预caching页面，但是当用户点击页面时会得到更快的响应。 我不确定这是否仍然适用，但是如果是这样的话，那么从理论上讲，一旦用户login，带有这些加速器之一的用户就会被踢出应用程序，因为她的加速器会find并检索注销即使她从来没有点击过它的链接。
到目前为止，我读过的所有东西都表明POST应该用于“破坏性行为”，而不会改变类似应用程序查询等内部状态的行为应该用GET来处理 。 基于此，这里真正的问题是：
注销被认为是破坏性行为的应用程序/它是否会改变应用程序的内部状态？
使用POST 。
在2010年，使用GET可能是一个可以接受的答案。 但是今天（2013年），浏览器将会预读他们“认为”你将访问的页面。
这是在Twitter上讨论这个问题的StackOverflow开发人员之一：
我想感谢我的银行注销GET请求，并感谢Chrome团队提供便捷的URL预取.- Nick Craver（ @Nick_Craver ） 2013年1月29日
有趣的事实：StackOverflow用于处理通过GET登出，但不再。
在REST中应该没有会话，因此没有什么可以销毁的。 REST客户端在每个请求上进行身份validation。 login或退出，这只是一个幻想。
你真正要问的是，如果浏览器继续发送每个请求的authentication信息。
可以说，如果你的应用程序确实造成了login错觉，那么你应该能够使用JavaScript“注销”。 不需要往返。
菲尔德论文 – 第5.1.3节
客户端到服务器的每个请求都必须包含理解请求所需的所有信息，并且不能利用服务器上存储的任何上下文。 会话状态因此完全保留在客户端上
GET可能被滥用的一种方式是，一个人（竞争者也许:)在网上随时随地用src="<your logout link>"放置一个图像标签，如果你的网站用户在这个页面上绊倒了，他会不知不觉就登出了。
注销对应用程序本身没有任何影响。 它改变了与应用程序有关的用户状态。 在这种情况下，看起来你的问题更多的是基于用户如何启动这个命令来开始这个动作。 由于这不是“破坏性行为”，因此确保会话被放弃或销毁，但是您的应用程序或数据都不会被更改，允许这两种方法启动注销过程并非不可行。 这个post应该被任何用户发起的操作使用（例如 – 用户点击“注销”），而get可以被保留用于应用程序发起的登出（例如 – 检测潜在用户入侵的强制redirectlogin页面）。
为了正确，GET / POST（或其他动词）是对某些资源（由URL寻址）的操作 – 所以它通常关于资源的状态，而不是关于应用程序状态。 因此，在真正的精神，你应该有一个URL，如[host name]\[user name]\session ，然后'删除'将是注销行动的正确动词。
使用[host name]\bla bla\logout作为URL并非真正的REST完整方式（IMO），那么为什么要争论正确使用GET / POST呢？
当然，我也在我的应用程序中使用GET来注销url 🙂
预caching的场景是一个有趣的场景。 但是我猜测，如果很多网站inc不担心，那么也许你不应该这样做。
或者也许链接可以在JavaScript中实现？
编辑：据我了解，从技术上说GET应该是只读请求，不改变应用程序状态。 POST应该是写入/编辑请求改变状态。 然而，其他应用程序问题可能更喜欢GET而不是POST的一些状态改变的请求，我不认为这有什么问题。
那么如果你让你的web应用程序通过一个注销脚本放弃会话，你通常不需要。 通常，会话variables对于要放弃的会话是唯一的。
我看不到如何注销（降低用户权限）是一种破坏性的行为。 那是因为“注销”行动应该只对已经login的用户可用，否则它将被废弃。
包含在浏览器cookies中的随机生成的string全部代表您的用户会话。 有很多方法可以销毁它，所以有效的注销仅仅是为您的访问者提供的服务。
