REST风格API端点的正确设计规范是哪种？

第一种同资源路径绑定对应HTTP方法的设计完全符合行业通用的RESTful API最佳实践，不需要替换成第二种路径内嵌操作动词的写法，后者是HTTP API设计中明确不推荐的反模式。

• HTTP协议本身已经为不同操作定义了标准化的语义：GET对应查询、POST对应创建、PATCH对应局部更新、DELETE对应删除，在路径里重复写get/add/update/delete属于完全冗余的设计，没有任何实际价值。
• 这种写法违背了REST架构「路径定位资源、请求方法定义操作」的核心原则，后续接口扩展、权限配置、缓存策略适配都会额外增加复杂度。比如后续要给用户资源加头像上传、密码重置等操作，按照第二种写法就要不断新增/api/uploadUserAvatar、/api/resetUserPassword这类零散路径，资源和操作的对应关系会越来越混乱。
• 目前主流的API网关、CDN缓存、安全管控组件默认都是基于「HTTP方法+资源路径」做规则匹配的：比如GET请求默认可以被缓存、非GET请求默认会触发跨域预检、权限系统可以直接配置规则「普通用户允许对/api/user发起GET、PATCH请求，禁止发起DELETE请求」。如果用路径带动词的写法，这些通用规则全部需要自定义适配，平白增加不必要的开发维护成本。

你当前的第一种写法本身没有问题，如果你的接口是操作当前登录用户的个人信息（不需要传入用户ID参数），现有写法可以直接用。如果是要支持操作任意指定用户，可以把路径调整为REST更规范的复数资源+路径参数形式：

// 对用户集合的操作：创建新用户
router.post('/api/users', userController.createUser);
// 对单个指定用户的操作：查询、修改、删除
router.get('/api/users/:userId', userController.readUser);
router.patch('/api/users/:userId', userController.updateUser);
router.delete('/api/users/:userId', userController.deleteUser);

你提到的第二种写法本质是RPC风格的接口设计，仅适合极少数内部强耦合的特殊服务场景，对外提供HTTP API时不要采用这种设计。

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