APIView vs ViewSet, 실무에서 사용하는 명확한 기준
DRF의 핵심 컴포넌트인 APIView와 ViewSet의 차이점을 이해하고, 실무에서 어떤 상황에 무엇을 선택해야 하는지에 대한 기준 제시
APIView: 모든 것의 기초
Django의 기본 View 클래스를 계승하여 DRF 핵심 기능을 추가한 가장 기본적인 클래스
특징
HTTP 메서드에 직접 매핑:
get(),post(),put(),delete()등을 클래스 내에 직접 정의명시적인 URL 설정: 각 View를
urls.py에as_view()로 수동 등록높은 자유도: URL 구조와 뷰 로직을 자유롭게 구성 가능
장점
명확성: 코드 흐름이 직관적
유연성: CRUD 패턴을 따르지 않는 복잡한 엔드포인트 구현에 적합
단점
코드 반복: 비슷한 CRUD 로직이 반복됨
수동 URL 설정: 모든 엔드포인트를 수동으로 등록
ViewSet: 관례를 통한 자동화
APIView를 기반으로 리소스 중심의 API를 쉽게 만들 수 있도록 여러 기능을 추상화한 클래스
특징
액션 기반 메서드:
list(),create(),retrieve(),update(),destroy()등 객체 조작 액션으로 메서드 정의자동 URL 라우팅: Router가 ViewSet을 등록받아 표준적인 RESTful URL 구조를 자동 생성
코드 재사용성 극대화: ModelViewSet 상속으로 몇 줄만으로 완벽한 CRUD API 구현
장점
생산성: 표준적인 CRUD API를 빠르고 간결하게 작성
일관성: 프로젝트 전체에 걸쳐 일관된 URL 구조와 API 설계 유지
코드 간결성: 반복 코드를 부모 클래스가 처리
단점
내부 동작 복잡성: Router와 Mixin 동작 원리 이해 필요
유연성 부족: 표준 RESTful CRUD 벗어나는 구조는 추가 설정 필요
실무 사용 기준
ViewSet을 기본으로 사용
특정 모델에 대한 CRUD 기능을 API로 제공할 때
DRF 프로젝트의 80% 이상 해결 가능
APIView는 예외적인 경우에 사용
CRUD와 관련 없는 로직 (인증/인가, 파일 업로드, 외부 서비스 콜백)
하나의 URL에서 여러 모델을 복합적으로 다루는 특수 로직
/health-check같은 간단한 단일 동작 엔드포인트
실무 꿀팁
혼용 사용: 하나의 프로젝트에서 두 방식을 함께 사용하는 것이 정상적이고 권장되는 패턴
ViewSet + @action: ViewSet으로 CRUD 구현 후 특정 리소스에 종속된 커스텀 기능이 필요할 때 @action 데코레이터 활용
내부 동작 이해: 문제 발생 시 router.urls 출력이나 부모 클래스 코드 확인으로 디버깅
Last updated