Spring Data Rest中@RestResource对delete方法的影响及相关问题问询

我先还原下你的场景：你配置了一个Spring Data Rest仓库，想给REST API设置细致的安全规则，代码大致如下：

@RepositoryRestResource(collectionResourceRel = "someEntities", path = "someEntities")
public interface SomeEntityRepository extends PagingAndSortingRepository<SomeEntity, Long> {

    @Override
    @PreAuthorize("hasRole('ADMIN') or hasPermission(#id, 'SomeEntity', 'delete')")
    void deleteById(Long id);

    @Override
    @RestResource(exported = false)
    void delete(SomeEntity entity);

    // 其他方法...
}

但你遇到了反直觉的问题：调用DELETE /someEntities/{id}时返回405 Method Not Allowed，明明预期应该触发deleteById()并通过权限校验；反过来把@RestResource(exported=false)移到deleteById()上时，同一个DELETE请求却能正常执行。下面逐个解答你的疑问：

Q1：为什么会出现这种语义上不合理的功能层面问题？ #

这是Spring Data Rest早期版本的一个设计细节——它在映射REST的DELETE请求到仓库方法时，优先级是delete(T entity)高于deleteById(ID id)。也就是说，当你调用DELETE /someEntities/{id}时，框架会优先尝试匹配delete(SomeEntity)方法，而不是按REST语义去匹配deleteById(Long)。

你给delete(SomeEntity)加了@RestResource(exported = false)，相当于把这个方法的REST出口关掉了，但框架还是会优先匹配它，发现它被禁用后直接返回405，根本没去读取deleteById()的配置。而当你把exported=false移到deleteById()上时，delete(SomeEntity)没被禁用，框架就会调用它——它内部其实还是会通过查询实体后调用deleteById()完成操作，所以你看起来请求正常执行了，但实际上绕开了你在deleteById()上的权限校验。

这个设计确实反直觉，因为从REST语义来说，根据ID删除理应对应deleteById，但框架早期是按参数类型匹配优先级来处理的，delete(T)因为能直接接收查询到的实体对象，被优先选中。

Q2：SimpleJpaRepository.delete()仅被deleteById()调用（无代理），Spring如何为delete()添加相关拦截器？ #

这里你可能误解了代理的作用范围：Spring Data Rest和Spring Security的AOP代理是针对整个仓库接口的，而不是针对SimpleJpaRepository的实现类。也就是说，当你在仓库接口的delete(SomeEntity)方法上添加注解时，Spring会为你的仓库接口生成代理对象，所有对仓库方法的调用（包括Spring Data Rest内部的调用）都会经过这个代理，从而触发Security的拦截器。

哪怕SimpleJpaRepository里deleteById()直接调用了delete(T)，但Spring Data Rest在处理请求时，是通过仓库接口的代理来调用方法的：它会先查询到对应的实体，然后调用代理后的delete(SomeEntity)方法，这时候AOP拦截器就会生效，和实现类内部的方法调用关系无关。

简单总结：仓库接口的所有方法都会被代理增强，只要接口上的方法有注解，不管是谁调用（包括框架内部），都会触发拦截逻辑。

Q3：是否存在该规则的例外情况？（原因是什么？） #

有两种例外情况：

• 当仓库接口没有重写delete(T entity)方法时，Spring Data Rest会自动使用deleteById(ID id)来处理DELETE /{id}请求，这时候你的权限注解就能正常生效。
• 如果你升级到Spring Data Rest 3.2.x及以上版本（对应Spring Boot 2.2+），这个方法匹配优先级的问题被修复了——框架会优先选择更符合REST语义的deleteById方法来处理ID路径的DELETE请求，你原来的配置就能按预期工作。

原因是社区反馈了这个反直觉的设计问题，所以后续版本调整了方法匹配逻辑，优先对齐REST语义。

更新部分：@PreAuthorize的特殊情况 #

你提到的@PreAuthorize只有hasPermission()有效、hasRole()无效的问题，同样是方法匹配优先级导致的：当框架调用的是delete(SomeEntity)方法时，你在deleteById()上的hasRole()注解根本没被触发；而如果delete(SomeEntity)上没有加任何权限注解，Spring Security的默认规则可能允许请求（或者你全局配置了其他规则）。而hasPermission()如果是在全局配置或者其他生效路径上，就会被触发。

官方文档里展示在两个delete方法上都加注解，其实就是为了覆盖两种可能的调用路径——因为框架可能会调用其中任意一个方法，所以需要给两个方法都加上权限规则，才能确保不管走哪个路径，权限校验都生效。

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