Rest 一次性下载链接是否符合HTTP规范？

在restful web服务的上下文中，GET方法的副作用是否可以接受

例如，一次性下载链接

GET /downloads/664d92b3-b373-4dac-a4fb-7a41d015109a

将在下一次请求时返回200和“TheThing”以及404

HTTP规范说GET方法应该是安全的，并且符合

如果请求方法的定义语义是安全的，则认为它们是“安全的” 基本上是只读的；i、 例如，客户机没有请求，而是 不期望源服务器上的任何状态因以下原因发生更改： 将安全方法应用于目标资源

及

安全方法的这种定义并不妨碍实现 包括潜在有害的行为，而不是 完全只读，或在调用保险柜时导致副作用 方法。然而，重要的是，客户没有这样做 要求对其他行为负责，并且不能追究其责任 它

提供了几个澄清的示例，这些示例使我认为不允许使用安全方法故意删除资源

例如，大多数服务器将请求信息附加到访问 在每个响应完成时记录文件，无论 方法，这被认为是安全的，即使日志存储可能 变满并使服务器崩溃

及

同样，启动了安全请求 通过选择网络上的广告往往会有副作用 收取广告费的效果

及

例如，它是 基于Web的内容编辑软件在中使用操作的常见方法 查询参数，如“page？do=delete”。如果这样做的目的是 如果资源要执行不安全的操作，则资源所有者必须 当使用保险箱访问该操作时，禁用或不允许该操作 请求方法

单一使用链接显然是现实。我只是想知道他们是在滥用规范还是我不明白

---

有一个意见是可以的，但是对这些规范进行研究并理解其微妙之处是最有说服力的。

您的建议在某些情况下是可以接受的，不一定是滥用规范

首先，关于安全方法，他们说：

不应该有采取行动的意义，而不是 检索

以及“不应”一词（加上强调语）：

此短语或短语“不推荐”的意思是可能存在 在特定情况下存在正当理由 行为是可以接受的，甚至是有用的，但其全部含义 应理解并仔细权衡案例 实现此标签描述的任何行为

你链接到的新版本（我认为它取代了2616）没有使用“不应该”这个词，但他们也没有用“不得”来代替它。他们还承认，只要客户不承担责任，就不排除副作用。所以我认为安全方法的想法是一样的

既然规范承认有些情况是可以的，我们如何知道你的情况是否是这样？更重要的是，我们如何保持规范的“精神”，即确保我们没有滥用它

我想引用以下引语：

区分安全和不安全方法的目的是
允许自动检索过程（spider）和缓存性能
优化（预取）可以在不担心造成伤害的情况下工作

如果您的应用程序是私有intranet应用程序，并且您不关心此处提到的问题，那么您的方法是可以的。换句话说：考虑到GET可能发生的所有可能方式，你对这种副作用满意吗

在RESTful指导方针之外工作并不总是坏事。确保你了解它的影响是很重要的

综上所述，如果您正在寻找一种通过HTTP实现可靠、一致的一次性资源交付的方法，那么阅读Bill de hÓra的HTTPLR规范（）是非常值得的。这种方法依赖于客户端确认收到消息。您可以使用类似这样的方法，允许不知道一次性使用策略（爬行器等）的此用户代理获取资源，而不会产生副作用，但仍然允许参与的客户端在一次获取后使资源变得不可用

这样的事务性方法还有一个额外的好处，即允许客户机根据需要随时重新尝试下载。这一点很重要，因为否则服务器无法知道客户机是否成功接收到消息

---

如果您确实需要从服务器端对任何可能的用户代理强制执行一次性策略，那么您最初的方法可能是最好的，但请记住，这实际上是一个“最多一次”策略。

有时打破规范是唯一的方法，例如使用隐藏图像的网页访问计数器。使用GET请求，但更新计数器

然而，有些事情可能会出错。遵循规范的应用程序可以假定发出GET请求不会有任何副作用。因此，这是完全有效的，例如，对于某种启用了防病毒功能的电子邮件服务器，它可以跟踪电子邮件中的链接，以确保所有内容都是安全的。如果您在电子邮件中发送此“下载一次”链接，收件人将永远看不到它。出于同样的原因，一封电子邮件中包含两个不同链接的是非答案也很难部署。但也在一个网页中：我记得谷歌浏览了一个谷歌所知的独特的按用户页面的链接，这只是因为里面有一个分析脚本，而且因为该页面包含这些臭名昭著的带有副作用的链接，谷歌实际上正在改变访问它的人的答案

在hid的情况下，假点击并不是一个真正的问题