问题描述
我知道 http 动词的使用基于标准规范。但是我的问题是，如果我使用“GET”进行更新操作并编写代码逻辑来更新，它会在任何情况下产生问题吗？除了标准之外，还有什么原因可以将这些动词仅用于特定目的？
解决方法
我认为这是一个不错的问题。您在问一个假设：除了我们同意使用 GET 进行提取之外，做正确的其他还有什么价值吗？例如：除了“语义上很好”这一事实之外，还有其他价值吗？ HTML 中的一个类似问题可能是：“可以将 <div> 与 onclick 一起使用而不是 <button>？（答案是否定的）。
肯定有。客户端、服务器和中间体都根据使用的方法改变它们的行为。即使您的服务器可以处理 GET 以进行更新，并且您构建了一个使用它的客户端，您的浏览器仍可能会感到困惑。
如果您对此主题感兴趣，请不要在论坛上提问；阅读规范。 HTTP 规范告诉您客户端、服务器和代理在遇到某些方法、状态和标头时应该做什么。
从 RFC7231 开始
,我的问题是，如果我使用“GET”进行更新操作并编写代码逻辑来更新，它会在任何情况下产生问题吗？
是的。
一个简单的例子——假设客户端和服务器之间的网络不可靠；具体来说，有一段时间，HTTP 响应正在丢失。通用组件（如 Web 代理）可能会超时，然后注意到请求的方法令牌是 GET，第二次/第三次/第四次重新发送请求，您的服务器对每个 GET 请求执行更新。
让我们进一步假设这些多次更新操作会导致不良结果；我们应该把责任放在哪里？
第二个示例：您向某人发送更新操作链接的副本，以便他们可以在适当的时间向您发送请求。但是假设您在电子邮件中将该链接发送给他们，并且电子邮件客户端识别出 uri 并（作为性能优化）预取链接，从而过早地触发您的更新操作。我们应该把责任放在哪里？
HTTP 不会试图要求 GET 的结果是安全的。它所做的是要求操作的语义是安全的，因此它是实现的错误，而不是接口或该接口的用户的错误，如果发生任何事情导致财产损失 - {{3 }}
在这些和其他示例中，blame 正确地附加到您的服务器，因为 GET 具有标准化含义，其中包括请求语义为 Fielding,2002 的约束。
这并不是说在处理 GET 请求时不能有副作用； “点击计数器”几乎与网络本身一样古老。您在实施中有很大的自由度；只要尊重统一的界面，不会有太大的麻烦。
体验报告：我们的一个内部工具使用GET请求来触发调度；在我们精心控制的环境中（不是网络规模），我们可以侥幸逃脱，并且已经有很长一段时间了。
借用你的语言，肯定有一些场景会给我们带来问题；但鉴于我们的控制，我们设法避免了它们。
不过，如果请求开始来自我们精心控制的上下文之外，我不喜欢我们的机会。