为何URI中绝不能使用CRUD函数名称？

REST架构的核心是资源导向，URI的本质是用来标识资源，而非描述对资源的操作，这也是不能在URI中加入CRUD（Create/Read/Update/Delete）函数名称的根本原因，具体可以拆解为以下几点：

• 破坏资源抽象原则：URI的作用是定位"是什么"，比如/users/123清晰指向ID为123的用户资源；而/deleteUser/123把操作和资源绑定，模糊了资源本身的定义，让URI变成了操作指令，违背了REST的设计初衷。
• HTTP方法已承载操作语义：REST规范中，HTTP方法本身就是用来表达CRUD逻辑的，完全不需要在URI中重复声明：
  • GET对应Read：GET /users/123即读取指定用户信息
  • POST对应Create：POST /users即创建新用户
  • PUT对应Update：PUT /users/123即更新指定用户信息
  • DELETE对应Delete：DELETE /users/123即删除指定用户
    硬加CRUD名称会造成语义冗余，甚至引发接口设计混乱，比如同时存在/deleteUser/123和DELETE /users/123两种操作定义。
• 降低可维护与扩展性：如果URI中硬编码操作，后续扩展功能（如批量删除、软删除）时，不得不新增/batchDeleteUsers、/softDeleteUser/123这类臃肿的URI；而基于资源+HTTP方法的设计，仅需用DELETE /users（批量删除）、PATCH /users/123（更新状态实现软删）就能完成，简洁灵活。
• 违反统一接口约束：REST的统一接口要求通过标准方法和资源标识交互，使用CRUD命名的URI会打破这种统一性，导致接口风格混乱，增加团队协作的理解成本。

反例：/createUser、/updateUser/123这类URI既冗余又不符合规范，正确写法应为POST /users和PUT /users/123。

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