取消订阅链接是否需要幂等？ [关闭]答案

【问题标题】：Does unsubscribe link need to be idempotent? [closed]取消订阅链接是否需要幂等？ [关闭]
【发布时间】：2011-08-10 09:52:00
【问题描述】：

所以我们有一个取消订阅链接 - 这本质上是一个 HTTP GET。

appropriate RFC 说这应该是幂等的，但在我看来，用户的期望是他们点击链接来采取行动。

我已经实现了这一点，以便该链接将您带到一个页面，该页面有一个大的确认按钮，然后更新您的订阅，确认并显示您帐户的最终状态（我们有不止一种订阅）

但我想知道如果这个人只是跳过确认按钮阶段，这会不会是一个更好的用户体验......

“我是不是想多了？”这个问题的答案肯定是的，但我想知道人们对平衡幂等 GET 的最佳实践与不混淆用户期望的最佳实践的看法是什么……

【问题讨论】：

取消订阅页面的 GET 链接是幂等的，因为它总是生成相同的取消订阅页面（前提是您没有意外的副作用，例如计算两次点击）。是的，你想多了。
@Robert 在链接上取消订阅操作会很危险，预取站点的软件（应该是可能的）假设在 GET 上没有任何丢失（正如标准所说，请参阅罗斯的回答）。例如。见Google Accelerator
@Jonas：我不是这么说的。澄清一下，取消订阅链接应该生成一个取消订阅页面，该页面使用 POST 来执行取消订阅操作，而不是 GET。
@Robert：啊，我明白了，我误解了你的第一条评论。感谢您的澄清。
我很惊讶这家公司已经关闭了……这不是关于软件开发的吗？？

标签： http http-post user-experience idempotent

【解决方案1】：

我想说RFC2616 第 9.1.2 节所说的并不重要，因为您已经违反了第 9.1.1 节中更重要的定义：

特别是，已经确立了 GET 和 HEAD 方法不应该具有采取行动的意义除了检索。

想象一个网络爬虫（例如，谷歌）跟踪您的一个页面中包含此链接的所有链接的效果。您真的希望这会导致取消订阅操作吗？那肯定是糟糕的用户体验！

【讨论】：

链接在电子邮件中。不在线。您无法爬到任何包含确认按钮的页面。此外，这些链接不会以数字方式识别用户，因此有人不能只是循环遍历每个试图取消订阅的人。
“您无法抓取到任何包含确认按钮的页面”。我想，公平地说，这并不完全正确。允许 GET 的 URL 格式为 web.web.co.uk/[subscription-type]/[email-address]，允许 POST 的 URL 格式为 web.web.co.uk/[sub-type] /[操作]/[电子邮件地址]。因此，您可以获取一个巨大的电子邮件地址列表并尝试恶意订阅/取消订阅它们，但您极不可能猜出我们数据库中真正存在的电子邮件地址
@Paul：Ross 是对的 (+1)，使用链接 (GET) 删除内容很危险，例如最新的 chrome 浏览器可以从谷歌预取网站，它可能是自定义电子邮件客户端的情况，例如在 andriod 上，预取电子邮件中的所有链接以获得更好的用户体验，这应该适用于 HTTP 协议。另请参阅 Google Accelerator 预取网页以获得更快的互联网。
我们似乎处于不同的目的......我不是用 GET 删除 - 但我被推动通过这样做来改进用户体验。我只是在寻求确认（和学习）
但我不知道预取是什么......这似乎是那里的杀手锏！因此，如果 70,000 人拥有特定的自定义电子邮件客户端，那么 70,000 人会在不知情的情况下取消订阅。哎哟！

【解决方案2】：

在这种情况下，幂等意味着无论您单击链接多少次，它都会做同样的事情，即取消订阅您。有一些解决方案会在您返回时重新订阅您，这是一种触发器方法，即非幂等。您是否将其实现为立即取消订阅（作为有足够动力单击链接的用户，我的首选方法是确保这是他们想要做的）或带有确认的页面取决于您。只需确保无论用户点击您的链接多少次并完成了他们所完成的流程，在链接结束时仍然没有从您的列表中退订。

【讨论】：

【解决方案3】：

有趣的问题不是它是否是幂等的，而是它是否安全。不是，因此一个简单的 GET（例如，它可能是预取的）是错误的。

【讨论】：

你把我弄丢了。您的意思是通过 GET 取消订阅不安全吗？
是的，这就是他的意思。假设包含此链接的电子邮件正在基于 Web 的电子邮件客户端（例如、GMail）中阅读。当用户打开邮件项目时，一些浏览器会预先获取链接指向的页面，这样如果用户点击它们，它们就会加载得更快。不幸的是，您的 URL 将被视为可预取的，并且会触发该操作。
在此上下文中的“安全”是 RFC 2616 第 9.1.1 节的含义，我在回答中引用了它。