REST API：权限校验与请求验证的执行顺序及响应码疑问

这确实是个API设计里很常见的困惑，咱们一步步理清楚：

核心结论：建议先做请求数据合法性校验，再做权限校验 #

你的预期是对的——当请求里的userId=-1是无效值时，应该返回400 Bad Request，而不是403 Forbidden。原因主要有两点：

1. 贴合HTTP状态码的语义 #

• 400 Bad Request：明确表示客户端提交的请求参数本身存在错误（比如无效值、格式不符、缺失必填项），客户端需要修正参数后再重试。
• 403 Forbidden：表示服务器完全理解请求，但因为操作人权限不足拒绝执行——这前提是请求参数都是合法的，只是当前用户没有操作权限。

在你的例子里，userId=-1是无效的用户标识，本质是请求参数不合法，和权限没有关系。如果直接返回403，会给客户端错误的引导：客户端可能会误以为是自己的权限不够，而忽略了参数本身的问题。

2. 更高效的业务逻辑执行顺序 #

先校验参数合法性，可以提前拦截无效请求，避免无意义的权限判断逻辑执行。比如你不需要去查文件1的所有者是谁，因为当前请求的userId本身就不存在，根本没必要走到权限校验那一步。

具体的校验流程建议 #

按照这个逻辑，你的API接口可以遵循以下校验顺序：

• 第一步：基础参数校验
  验证所有请求参数的合法性：

  • userId是否为系统中存在的有效用户ID（比如不能是负数、非数字、不存在的ID）
  • granteeId是否为有效用户ID
  • role是否属于允许的枚举值（比如READER/WRITER等）
    只要有一项不合法，直接返回400 Bad Request，并在响应体里明确说明错误原因（比如"error": "无效的userId：-1，系统中不存在该用户"）。

• 第二步：权限校验
  当所有参数都合法后，再判断当前操作用户（userId对应的用户）是否有权执行该操作：

  • 对于POST /files/{id}/permissions，校验userId是否是文件{id}的所有者
    如果权限不足，返回403 Forbidden。

关于HTTP决策图的补充说明 #

你提到的HTTP决策图里“先判断is_forbidden再判断is_request_block_ok”，这是通用场景下的建议，但不适用于所有业务场景——尤其是你的API是内部使用、无需鉴权但依赖userId标识用户的情况。在这种场景下，userId是请求的核心参数，必须先确保它的有效性，才能进行后续的权限判断。

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