Spring构建层级API：嵌套URL与扁平化URL方案抉择

首先，方案二更优，且可以通过小调整弥补语义性的不足，同时推荐结合两种思路的折中方案，具体如下：

一、直接否定方案一的核心原因 #

• 全嵌套URL存在严重冗余：比如获取椅子仅需cabinetId，但URL携带的orgId、branchId、buildingId完全多余，既增加前端拼接成本，后端还要额外校验层级关联（比如该柜子是否属于指定建筑），徒增维护复杂度。
• URL过长会导致可读性差、前端拼接易出错，后续若扩展层级（如新增floor），URL会变得更臃肿。

二、优化方案二，兼顾简洁性和语义性 #

方案二的扁平化思路是对的，可通过分层路由+查询参数过滤保留语义，同时保持简洁：

1. 基础资源路由保持扁平化，每个资源对应独立Controller：
   • 组织：GET /api/orgs/{orgId}、GET /api/orgs
   • 分支：GET /api/branches/{branchId}、GET /api/branches
   • 建筑：GET /api/buildings/{buildingId}、GET /api/buildings
   • 柜子：GET /api/cabinets/{cabinetId}、GET /api/cabinets
   • 椅子/设备：GET /api/chairs/{chairId}、GET /api/chairs
2. 通过查询参数实现关联过滤，保留层级语义：
   • 获取某组织下所有分支：GET /api/branches?orgId={orgId}
   • 获取某分支下所有建筑：GET /api/buildings?branchId={branchId}
   • 获取某柜子下所有椅子：GET /api/chairs?cabinetId={cabinetId}
3. 后端可通过查询参数做关联校验（如确保传入的cabinetId确实属于指定buildingId），既保证数据正确性，又无需在URL中嵌套冗余参数。

三、特殊场景的补充处理 #

• 创建资源时，可用嵌套URL明确从属关系，比如创建某柜子下的椅子：POST /api/cabinets/{cabinetId}/chairs，语义清晰，后端可直接通过cabinetId关联新椅子，无需前端额外传参。
• 批量关联查询（如获取某组织下所有椅子），用GET /api/chairs?orgId={orgId}即可，后端通过关联查询实现，比多层嵌套URL更灵活。

四、Spring中的实现示例 #

• 每个资源对应独立Controller，比如OrgController、BranchController、ChairController，代码结构清晰，符合Spring MVC规范。
• 查询参数接收示例：

  @GetMapping("/chairs")
  public List<Chair> getChairs(@RequestParam(required = false) Long cabinetId) {
      if (cabinetId != null) {
          return chairRepository.findByCabinetId(cabinetId);
      }
      return chairRepository.findAll();
  }
  

• 关联资源创建示例：

  @PostMapping("/cabinets/{cabinetId}/chairs")
  public Chair createChair(@PathVariable Long cabinetId, @RequestBody Chair chair) {
      Cabinet cabinet = cabinetRepository.findById(cabinetId)
          .orElseThrow(() -> new ResourceNotFoundException("Cabinet not found"));
      chair.setCabinet(cabinet);
      return chairRepository.save(chair);
  }
  

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