Django Rest Framework 3. view of DRF

0.view of DRF

view of DRF

DRF에는 view를 작성하는 방법이 여러가지 있다.

(지난 2편에서는 serializer쓰고, 모델기반의 viewset상속하는 방법으로 view를 작성했지! ViewSet은 view(CRUD)를 구현하는 DRF의 쉽고 간단한 view설계 방법이다.)

view의 종류 중 위 그래프를 보면 왼쪽에서(API View) 오른쪽(ViewSet)으로 갈 수록 코드 복잡도가 낮아 지는데 이는 상속을 통해 이루어지는 것이다. APIView는 2편의 Django기반 CBV와 유사항 형태이므로 익숙하니깐 APIView에서 시작해 ViewSet까지 순서대로 django_rest_framework의 GitHub문서와 튜토리얼을 보고 3편의 실습 예제였던 Post의 view를 작성해보자. 

view의 상속

DRF view의 상속관계는 위와 같다. APIView는 View를 상속하고 Mixins는 APIView를 상속하고...

공식홈페이지: https://www.django-rest-framework.org/

                 튜토리얼 중 3.Class based views와 6.ViewSets and routers

rest_framework의 Github 주소: https://github.com/encode/django-rest-framework/tree/master/rest_framework

 

 

 

 

1.APIView

다음은 튜토리얼에서 볼 수 있는 APIView를 상속해서 만든 모든 오브젝트들을 보여주는 역할 하는 view의 예시이다.

우선 모델과 serializer를 임포트 했고 APIView외에도 Response,status,Http404를 임포트하고 있다. SnippetList클래스는 모든 오브젝트 보여주는 view이므로 들어오는 요청인 HTTP메소드들은 get과 post뿐이다. 

즉,APIView를 상속해서 CBV를 정의할 때 내용에 함수이름은 http메소드여야하고 함수의 내용은 직접 정의할 수 있다. 따라서 Response와 status등을 추가로 임포트 한 것!

클래스 이름은 기능에 따라 (모델이름)List,(모델이름)Detail등 이지.

+urls.py도 튜토리얼을 따르면 조금씩 다르지.

 

PostList클래스에 put,delete함수를 정의하면 이들 기능도 사용 할 수 있다.

API View를 통해서 어떤 http메소드 요청받았을 때 어떤식으로 내부적으로 처리할고 response를 돌려줄지 직접 커스터마이징하는 과정은 조금 더 가시적인 장점이 있다. 단점은 서로 다른 모델의 view기능이 비슷해도 반복해서 같은 내용을 쓰기에는 코드가 길다. 비슷한 논리가 여러 모델들에 대해 계속 반복하면 낭비고 비효율이니깐 빨리 Mixin을 보자!

 

2.Mixins

 

상속을 통해 불필요한 중복제거했다. APIView와 모습이 다르고 훨씬 짧아졌다!특징은 
-mixins와 generic임포트
-기능에 따라 상속이 약간 많아졌다.
-쿼리셋과 serializer클래스를 함수 외부에 등록  
-http메소드 이름으로 함수와 한 줄짜리 return문이 있다.return문에는 create, list, retreive, destory등의 기능을 하는 함수가 온다.

 

github 의 django-rest-framework의 문서에서 상속하는 GenericAPIView클래스 보면 queryset과 serializer_class라는 있는 변수에 지정하는 것 하는 것이다.

(모델이름)List클래스에서 http메소드 이름의 함수 인자로 sef,request,가변인자들 받아 get은 list리턴(ListModelMixin에 정의된),post는 create(CreateModelMixin에 정의된)리턴
(모델이름)Detail클래스에서 get은 retrieve메소드return하는데 이는Mixin클래스안에 정의되어있다. 역할은  APIView의 Detail클래스의 get메소드(특정 pk로 불러오는) 동일하다. put메소드에는 update를, delete요청에는 destroy를 리턴하는데 각각 상속하는 view의 github문서에 정의되어 있다.

+url은 APIView와 동일하다

+Post모델에 대한 Mixins상속한 view는 맨 아래의 github주소 보자

 

3.Generic Class Based View

 

generics를 상속하는 클래스의 예시를 튜토리얼에서 가져왔다. generics는 mixins를 상속해서 정의되어 있기에 코드의 길이가 훨씬 짧아졌다. (모델이름)List클래스와 (모델이름)Detail클래스 둘의 예시를 가져왔는데도 짧다.

당연히 모델과 seralizer를 그래도 import하고 generics만 임포트 했다. 필요한 클래스를 상속해 쿼리셋과 serializer를 지정해 주는 것이 다 이다.

 

4.ViewSets

 

튜토리얼의 예시가 아닌 github의 viewsets.py먼저 살펴보자.

다른 클래스들도 있지만 ReadOnlyModelViewSet과 ModelViewSet를 가장 많이 쓰기에 둘 만 가져왔다. 둘의 내용은 정말 없다. 상속해서 하나로 묶어주는게 다 이다.

상속으로 get(),post()같은 메소드 핸들러가 없음에도 `list()`, `retrieve()`, `create()`과 같은 액션을 지원하고 있다.

 

 

 

 

 

 

-ReadOnlyViewSet: 
list()와 retrive()를 통해 가져다 주기만 한다.정말로 readonly다
쿼리셋과 serizlizer만 지정하면 된다
-ModelViewSet: 
CRUD모두 가능! 쿼리셋과 serializer,추가로 permission_class지정:그 액션을 할 수 있는 권한을 설정하는 부분
*@action()인자의 renderer_class: Response를 어떤형식으로 Rendering시킬 것인가(깃헙 renderer.py)

 

튜토리얼의 예제이다. ModelViewSet을 상속하고 있다. 쿼리셋과 serizlier를 지정해준다. 추가로 permission_classes도 지정해주었다. @action decorator로 CRUD외의 기능을 추가해줬다.렌더링할 클래스를 GET으로 받았을 때 HTML로 highlight하거나 save하는 역할인가보다~!

urls.py도 viewset을 사용하면 달라진다. router를 사용하는데 이는 다음편에서 알아보자.

 

 

 

*추가로 알아보는 @함수이름()의 의미

@+함수이름() 이러한 형식 가진것을 decorator,장식자라 한다. ViewSet으로 기본 CRUD는 구현가능!CRUD가 아닌 다른 logic들 위한 custom API구현하고 싶을 때 action decorator를 사용한다 (->1번의 APIView를 상속해 만드는 CBV와 동일!) 따라서 위 예제처럼 Response등을 임포트 해서 사용할 수 있다. 첫번째 인자로 어떤 http메소드를 받을지전달하는데 없으면 get이다. 두번째 인자로는 rendering할 클래스를 받는다.

 

이와 같이 DRF에서 여러 종류의 View들을 알아봤다. 상속의 단계가 높아질수록 코드의 중복을 피하고 간단해졌다.

다음엔 urls.py에서 사용하는 router에 대해서 알아보쟈.

아래는 참고한 사이트들이다.

https://github.com/encode/django-rest-framework/tree/master/rest_framework

encode/django-rest-framework

https://www.django-rest-framework.org/tutorial/3-class-based-views/

3 - Class based views - Django REST framework

https://github.com/kangtegong/django-RESTful-API2/tree/master/post

kangtegong/django-RESTful-API2

⬆ 2편 실습에서 해봤던 Post모델기반 CRUD구현하는 view를 APIView부터 ViewSet까지 다양한 방법으로 작성한 코드들을 담고있다. 언제나 무한 감사 😙