기본적으로 Rails는 자식 리소스의 모든 액션에 대해 완전한 중첩 경로를 생성합니다. 이는 엔티티 간의 관계(예: 앨범 → 사진)를 존중하지만, /albums/12/photos/42/edit와 같이 장황하고 중복되는 라우트 구조로 빠르게 이어질 수 있습니다. RESTful 관점에서 볼 때, 자식 리소스가 자체 ID로 고유하게 식별될 수 있는 액션에서는 이러한 중첩이 불필요합니다.
shallow: true 옵션을 사용하면 라우팅 동작이 변경되어 컨텍스트가 필요한 액션(일반적으로 index 및 create)만 중첩된 상태로 유지됩니다. 다른 모든 액션(show, edit, update, destroy)은 자식 리소스의 ID를 사용하여 최상위 라우트로 생성됩니다. 예를 들어, resources :albums do; resources :photos, shallow: true; end와 같은 구성은 GET /albums/:album_id/photos (index) 및 POST /albums/:album_id/photos (create)와 같은 중첩된 경로와 함께, GET /photos/:id (show), PATCH /photos/:id (update), DELETE /photos/:id (destroy), GET /photos/:id/edit (edit)와 같은 최상위 경로를 생성합니다.
이러한 접근 방식은 리소스 관계의 의미론적 명확성을 유지하면서 라우트의 단순성을 희생하지 않습니다. shallow 라우트 구현은 다음과 같은 여러 실질적인 이점을 제공합니다:
- 향상된 URL 디자인: /photos/42 대 /albums/12/photos/42와 같이 더 깔끔하고 직관적인 엔드포인트를 제공합니다.
- 분리된 컨트롤러 로직: shallow 라우트를 처리하는 컨트롤러는 params[:id]를 통해 리소스에 직접 접근할 수 있어 부모 모델을 로드할 필요가 없습니다.
- 확장성: 특히 자식 리소스의 복잡성이 증가하거나 독립적으로 진화할 때 리소스 처리를 단순화합니다.
- RESTful 무결성: 각 리소스가 정식 URI를 통해 접근 가능해야 한다는 원칙에 부합합니다.
그러나 shallow 라우팅이 항상 최적의 솔루션은 아닙니다. 자식 리소스가 부모와 독립적으로 존재할 수 없거나 존재해서는 안 되는 경우(예: 항상 프로젝트 및 작업의 컨텍스트를 필요로 하는 댓글), 참조 무결성을 보장하고 고아 접근 가능성을 줄이기 위해 완전한 중첩을 강제하는 것이 바람직할 수 있습니다. 예를 들어, resources :projects do; resources :tasks, shallow: true do; resources :comments, shallow: true; end; end와 같은 깊은 계층 구조에 shallow: true를 적용하면 계층적 모델 구조를 존중하면서도 최종 URL, 특히 댓글과 같은 하위 리소스에 대한 불필요한 중첩을 피할 수 있는 경로가 생성됩니다.