点击按钮执行操作时用GET替代PUT等HTTP方法是否存在实际问题？

• GET请求做修改操作的安全和逻辑漏洞
  按规范GET属于安全、幂等且可被缓存的方法，仅用于读取资源。如果用它实现点赞、状态修改这类写操作，会遇到多个问题：浏览器预加载机制可能提前触发请求、爬虫爬取页面时意外执行操作、用户刷新页面会重复提交请求。更严重的是GET请求默认不受Rails CSRF校验保护，攻击者可以在恶意页面植入<img src="https://你的站点/posts/123/like">，只要登录用户访问恶意页面就会自动执行点赞操作，你配置的权限策略根本防不住这类CSRF攻击。
• 额外增加Rails生态下的开发维护成本
  Rails默认的RESTful路由体系是和HTTP方法绑定的，符合约定的写法只需要几行代码就能生成规范路由、接口映射，违背约定需要手动编写大量自定义路由，后期维护人员查看路由时无法直观判断接口是读操作还是写操作，容易出现误调用、错改逻辑的问题。
• 幂等性失效导致业务异常
  HTTP规范中PUT/PATCH是幂等方法（多次调用效果和调用一次一致），POST是非幂等方法，GET/HEAD是安全方法。如果把非幂等的操作（比如邮件重发）用PUT实现，网络波动时浏览器、反向代理会自动重试请求，可能导致用户点一次按钮就收到多封重复邮件；反过来如果把修改发布状态这类幂等操作用POST实现，你需要额外开发防重复提交的逻辑，平白增加工作量。
• 缓存策略完全失效
  所有的浏览器、CDN、反向代理都会默认缓存GET请求的响应，如果把写操作做成GET，可能出现用户执行操作后返回缓存的旧结果，操作半天不生效的问题。反过来如果把查询类的读操作用POST实现，就没法享受到HTTP层的缓存能力，接口性能会明显下降。
• 排查问题和团队协作成本提升
  主流的日志分析、APM监控工具都会默认按HTTP方法分类统计请求，如果你把写操作散落在各类HTTP方法中，排查线上问题时很难快速筛选出对应的写请求，需要额外加自定义标记。同时开发团队默认都遵循HTTP方法约定，跨前端、后端协作时还需要额外同步每个接口的实际作用，沟通成本大幅提升。

内容的提问来源于stack exchange，提问作者OuttaSpaceTime