如何设计并验证JAX-RS REST API子资源访问以避免代码重复

方案1：抽取业务校验公共服务层 #

• 保持「每个Dao仅被对应Service调用」的单一职责约定，在CustomerService中封装统一的validateCustomerExists(Long customerId)方法：内部调用CustomerDao查询指定ID是否存在，不存在直接抛出统一的业务异常（如CustomerNotFoundException，可搭配全局异常处理器直接映射为404响应）。
• 所有需要校验客户存在性的关联资源Service（如AddressService、后续新增的订单/会员卡等Service），直接注入CustomerService调用该校验方法即可，无需直接依赖CustomerDao，既避免了Dao层的耦合，也完全消除了校验逻辑的代码重复。
• 优势：完全符合分层设计规范，校验逻辑集中维护，后续修改校验规则只需要改一处即可。

方案2：利用JAX-RS过滤器做路径参数统一校验 #

• 自定义CustomerExistsCheckFilter实现ContainerRequestFilter，绑定匹配所有路径前缀为/customers/{id}/**的请求：

@Provider
@PreMatching
public class CustomerExistsCheckFilter implements ContainerRequestFilter {
    @Inject
    CustomerService customerService;

    @Override
    public void filter(ContainerRequestContext requestContext) throws IOException {
        // 从路径参数中解析customerId
        String customerIdStr = requestContext.getUriInfo().getPathParameters().getFirst("id");
        if (customerIdStr != null) {
            Long customerId = Long.parseLong(customerIdStr);
            try {
                customerService.validateCustomerExists(customerId);
            } catch (CustomerNotFoundException e) {
                requestContext.abortWith(Response.status(Response.Status.NOT_FOUND).entity("客户不存在").build());
            }
        }
    }
}

• 优势：校验逻辑完全下沉到请求入口层，业务层的Service/Resource都不需要再处理客户存在性校验，后续新增的所有customer下的嵌套资源自动生效，耦合度最低。

补充兜底方案：数据库外键约束校验 #

在Address表的customer_id字段设置非空外键，关联Customer表的主键，即使上层校验漏过，数据库也会直接抛出外键约束违反异常，可通过全局异常处理器转换为对应错误响应，避免脏数据写入。

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