REST端点设计禁用动词时 无保存意图的校验接口如何设计

首先要纠正一个常见的认知偏差：很多人对“REST接口路径不能使用动词”的规则理解过于机械，这条规则的核心要求是用路径完成资源定位，用HTTP方法表达操作语义，不是要把所有动作相关的词都从路径里赶出去，只要路径成分是名词性的资源标识，就完全符合规范，没必要为了凑规则扭曲业务逻辑的清晰度。

推荐方案：抽象校验报告资源 #

最符合REST语义、也最清晰的设计是把「表单校验结果」抽象为一类临时资源，接口设计为：
POST /employee/basic/validation-reports

• 路径全为名词性成分，完全没有动词，符合规范要求
• 语义非常明确：针对员工基本信息模块，提交当前填写的片段数据，生成对应的校验结果
• 不需要纠结“这个资源没有持久化是不是不符合REST”：REST从来没要求所有资源必须永久存储在服务端，临时计算生成的结果（比如搜索结果、计算结果、校验结果）同样属于资源范畴，和你调用搜索接口拿到的临时结果集逻辑完全一致
• 和已有的正式保存接口POST /employee/basic/边界非常清晰：后者是提交正式数据，执行校验+持久化，生成正式的员工基本信息资源；前者仅处理临时提交的片段数据，做规则校验后返回结果，不落地任何业务数据

接口的交互逻辑也非常顺畅：

• 请求体直接传当前标签页用户填写的表单内容
• 校验不通过时返回400 Bad Request，响应体携带各字段对应的错误列表
• 校验通过时返回200 OK，响应体标记校验通过状态，前端拿到后直接跳转下一个标签页即可

备选简化方案：使用名词化的校验环节资源 #

如果团队觉得validation-reports的表述偏长，也可以用REST体系中公认的控制器资源（Controller Resource）模式——这是Roy Fielding本人明确提到的适用于计算、校验这类无持久化动作场景的例外设计，不需要硬套实体资源模型：
你可以把“基本信息校验环节”抽象为一个名词性的节点资源，接口设计为：
POST /employee/basic/validation
注意这里用的是名词形式的validation（校验环节/校验流程），而不是动词原形的validate，路径全程都是名词性定位，完全不违反“路径不使用动词”的要求，开发和前端看路径也能一眼明白接口的作用。别担心validation看起来和动作相关，它在这里是明确的名词性成分，指代“校验流程”这个资源节点，和大家常用的/login（指代登录流程节点，不是动词“登录”）是完全一样的逻辑，不算违反规则。

几个不推荐的踩坑写法 #

• 不要为了“贴合REST”强行把校验逻辑合并到正式保存接口，靠自定义请求头（比如加X-Validate-Only: true）区分执行分支：这会直接破坏接口的单一职责，保存接口本就应该只处理正式提交、数据持久化的逻辑，临时校验单独拆端点，后续迭代维护的成本要低很多
• 不要用GET方法传参做校验：GET的语义是获取已存储的资源，且表单数据放在URL参数里存在长度限制、敏感信息泄露风险，完全不适合提交半填写的表单片段做校验
• 不要硬套PUT/PATCH方法：这两个方法的语义是更新已存在的持久化资源，而校验阶段用户填写的是还未落地的临时草稿数据，根本没有对应的已存储资源，用POST才是语义最匹配的选择

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