REST 是个名词，不是规范书

每次接口评审都会有人争论"这不是 RESTful 的"。我的观点一直没变：Fielding 那篇论文里的 REST 是一种架构风格的描述，不是接口设计规范。今天大多数号称 REST 的 API，实现的是"资源化 URL + 合理状态码 + HTTP 动词语义"，这已经足够好。

先说动词。GET/POST 用满全项目没问题，PUT 和 DELETE 在网关、代理、老客户端上坑不少（有些防火墙直接拦 DELETE）。业务上用 POST /users/42/disable 代替 PATCH /users/42 传一个状态字段，可读性反而更高——把"意图"放进 URL，比把意图藏进 body 里的某个枚举值清楚。

再说 HATEOAS。理论上客户端应该靠响应里的链接发现自己能做什么，现实是没有任何前端愿意解析这种链接。它适合开放平台（让第三方顺着链接走），内部系统完全没必要。

真正值得死磕的只有三件事：

资源命名的一致性：全小写、复数名词、层级不超过两层（/orgs/1/projects/2/tasks 再往下就该用查询参数了）。

错误的形状：错误响应的结构必须全站统一，比如 {"code": "TASK_NOT_FOUND", "message": "..."}，前端只需要写一次错误处理。

分页的形状：游标分页（cursor）在数据频繁增删时比页码分页稳得多，尤其是列表有实时写入的场景。

把力气花在这三处，比争论"要不要用 PUT"有价值得多。