【软件设计】14个REST API评审的负面清单

评审接口时，最怕的不是代码写得烂，而是大家各说各话。所以我把常见坑整理成了一份负面清单，直接贴在工位上。

其实这 14 个病句，根上就三个毛病。一是 RPC 思维，把动词硬塞进路径；二是忽略了分布式环境，忘了重试和集群；三是把语义私有化，搞得网关全瞎。

最容易踩坑的是 GET /deleteUser。嘴上说看看，手上却在删数据。爬虫一爬、浏览器预取一触发，数据就没了。加鉴权都没用，因为请求是合法的。

还有那个“全部返回 200”的头号大坑。动作明明失败了，HTTP 状态码却报成功，真正的错误藏在 body 里。网关看到 200 就以为没事，不会重试也不会告警。监控看板一片绿，但业务早就崩了。

规范不是用来挑刺的。它只是把“我觉得不太好”，变成“这里违反了第几条规定”。评审会因此从主观吵架，变成了事实核对。