REST API服务方法设计：权限校验应内嵌还是独立调用？

两种方案的优劣分析 #

方案1：基础方法自行调用权限校验 #

• 优势：
  • 代码复用性强：所有调用基础CRUD方法的场景（包括控制器、内部服务调用）都会自动触发权限校验，无需重复编写校验逻辑。
  • 业务逻辑完整性：基础方法负责从权限校验到业务操作的完整流程，调用方无需关注权限细节，降低认知成本。
• 劣势：
  • 灵活性受限：如果存在无需权限校验的特殊场景（如系统后台批量操作），需要给基础方法增加开关参数，增加复杂度。
  • 排查问题繁琐：权限校验逻辑被封装在基础方法内部，调试时需要深入到方法内部定位权限错误。
  • 错误处理分散：权限相关的异常会在基础方法中抛出，需要确保控制器或全局异常处理器能统一捕获处理。

方案2：控制器先校验，再调用基础方法 #

• 优势：
  • 职责边界清晰：控制器专注于请求入口的权限校验与参数校验，基础方法只负责纯业务逻辑，代码分层更清晰。
  • 调试直观：权限校验在入口层执行，出现权限问题时能快速定位到控制器的校验逻辑。
  • 灵活性高：不同接口可以根据需求调整校验规则，甚至在合法场景下跳过校验（如管理员接口）。
• 劣势：
  • 代码冗余：每个CRUD接口都需要重复编写权限校验逻辑，增加维护成本。
  • 易遗漏校验：新增接口时如果忘记添加权限校验，会直接导致权限漏洞。
  • 耦合性高：权限逻辑与控制器绑定，若其他内部服务需要调用基础方法，必须自行实现权限校验，容易出现逻辑不一致。

实操建议 #

如果项目规模较小，且没有复杂的特殊权限场景，优先选择方案1，但要注意：

1. 把权限校验封装成独立的工具类或服务，让基础方法调用这个统一的校验逻辑，避免重复代码。
2. 给基础方法预留可选的skipAuth参数，用于合法的无权限校验场景。
3. 配置全局异常处理器，统一捕获权限校验失败的异常，返回标准化的HTTP错误响应（如403、404）。

如果是中大型项目，推荐使用切面/中间件实现权限校验：

• 把权限校验逻辑抽离成独立的切面（如Spring AOP、Express中间件），通过注解或路由匹配自动触发校验。
• 这种方式既避免了控制器的代码冗余，又不会让基础方法耦合权限逻辑，同时能统一管理所有接口的权限规则。

内容的提问来源于stack exchange，提问作者Nono-Man