REST API中用GET动词执行更新操作会有哪些问题？为何要规范http动词用途

哪怕你完全按照业务逻辑写好了更新流程，让GET请求能正常完成资源修改，这种实现也会在绝大多数生产场景下触发非预期的异常，常见的问题包括：

• 中间组件的默认行为错配：浏览器、CDN、反向代理这类组件默认会将GET请求识别为只读请求，自动对响应做缓存、对页面内的GET链接做预取。如果你的更新逻辑挂在GET路由下，可能出现用户还没主动点按钮触发操作，浏览器就为了提速自动预取链接，提前把更新执行了；或者用户好不容易触发一次更新，后续所有相同的GET请求直接被缓存层拦截，根本不会走到业务服务器，本该执行的更新逻辑完全失效。
• 非人为触发的误操作：搜索引擎爬虫、合规扫描器这类自动化工具，通常只会自动顺着页面里的GET链接爬取，不会主动提交POST/PUT这类带写操作的请求。如果你的更新接口用GET实现，爬虫爬取页面的过程就可能直接触发更新逻辑，比如触发"清空30天前的临时订单""批量重置用户配置"这类操作，整个过程完全不受用户控制。此外如果用户不小心把带更新逻辑的GET链接存到了收藏夹，或者误点了浏览器历史记录里的对应链接，也会无预期触发重复更新。
• 非预期的重复执行：因为GET默认被定义为幂等、无副作用的请求，网络中间节点、客户端SDK在遇到请求超时的时候，会自动重试这类请求。如果你的更新逻辑本身不具备幂等性（比如"给用户账户加100积分""提交一次反馈工单"），一次正常的用户操作就可能因为自动重试被重复执行多次，直接造成业务数据错误。
• 安全规则的防护缺失：WAF、CSRF防护这类安全组件，默认会按照标准语义对GET请求降低校验强度——按照HTTP标准定义，GET属于安全方法，语义上不应该产生任何服务器端的资源状态修改，很多防护规则会默认跳过GET请求的CSRF校验。把更新操作挂在GET路由下，相当于直接把这类接口暴露在跨站请求伪造的攻击风险下，攻击者只要构造一个嵌入了该GET链接的恶意页面，登录状态的用户访问时就会被自动触发更新操作。

抛开标准规范的硬性要求，这种约定本质上是为了降低整个HTTP生态的协作成本、减少系统错配风险：

• 全生态的默认行为对齐：所有基于HTTP协议开发的工具、组件、框架，都是按照标准定义的动词语义设计的，从浏览器的请求处理逻辑到CDN的缓存规则，从监控系统的指标采集到自动化测试框架的用例设计，大家的默认认知都是统一的。如果打破这种语义约定，你就需要为每一个相关组件单独做适配调整，不仅改造成本极高，还很容易因为漏配置出现线上故障。
• 安全防护的自动化覆盖：现有的安全体系会基于动词的语义自动匹配对应的防护策略，比如对写操作类的接口自动强制做CSRF校验、加请求频率限制、留存完整的操作审计日志。如果偏离标准使用动词，这些自动化防护就不会覆盖到你的业务接口，你需要额外从零开发对应的防护能力，稍有不慎就会出现安全漏洞。
• 团队协作的可维护性：团队内部的所有开发者、运维人员、测试人员，对HTTP动词的语义认知都是统一的。比如看到GET接口就默认知道这是只读查询，排查问题的时候会优先查缓存、查路由匹配，不会预判这个接口会触发服务端的写操作。如果把更新逻辑放到GET接口里，后续接手的开发很可能因为不知道这个"特殊约定"，误给接口加全局缓存、做自动预取，直接引发生产故障。
• 降低跨团队的沟通成本：当接口按照标准语义匹配对应动词时，不管是前端开发、第三方对接方，只要看到请求方法，就能快速判断接口的功能边界，不需要逐字逐句抠接口文档才能区分哪些接口是只读的、哪些接口会修改服务端数据，大幅减少对接过程中因为语义理解偏差导致的bug。

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