DRF Tutorial

---

1. Serializer

---

Serializer는 마치 django의 form 처럼 역직렬화 과정에서 건내 받은 데이터의 유효성 검사를 한다.
Serializer.data는 dcit type 이다.

1) ModelSerializer

1. 자동으로 필드 셋을 결정해줌
2. Serializer의 create() 및 update() 메소드를 간단하게 구현해줌.

궁금한 점

write 모드일 때 커스터마이징을 하려면, Views를 만져줘야하나, Serializers를 만져줘야 하나.

• 인강에선 Views를 만져줬음. Django 의 MVT 패턴이면 여기서 만져주는 게 맞는 것 같음.
• 근데 튜토리얼 보면서 Serializers에서 만져줘야한다고 생각했는데, 역직렬화 과정에서 Serializer의 create(), update() 메서드는return instance.save()을 해주므로, 결국 인스턴스 write에 마지막으로 접근하는 것은 seriazlier니깐 그러지 않을까? View까지 공부해보면 해결될 수 있을 것 같다.

일단 내린 결론은, View가 그렇게 짜여진 serializer를 호출하는 역할을 해주는, urls와 serializers의 중간에서의 컨트롤러의 역할을 하는 것 같다.

---

---

2. Reqeusts and Responses

---

1) Request

HttpRequest를 보다 확장하고 유연한 요청 구문 분석을 제공한다.

request.POST  # Only handles form data.  Only works for 'POST' method.
request.data  # Handles arbitrary data.  Works for 'POST', 'PUT' and 'PATCH' methods.

request.data 는 JSON뿐 아니라 다양한 포맷의 요청을 파싱해서 얻은 파이썬의 딕셔너리이다.(type(request.data) == dict이다) 이것이 유용한 이유는 writing 모드에서 들어온 데이터를 직접 파싱을 하지 않아도 된다는 것이다. 즉, 이전에는 data = JSONParser().parse(request)라고 직접 입력하였는데, 그럴 필요 없이 request.data라고 하면 끝이다.
DRF의 Request를 사용하려면 밑의 3) 을 진행해야한다.

2) Response

Djanog의 SimpleTamplateResponse을 상속받아 일종의 TamplateResponse 역할을 한다. content에 대해 올바른 랜더링 타입을 클라이언트에게 리턴해준다. 즉 HttpResponse, JsonResponse 등을 구분해서 사용하지 않아도 Response가 결정해준다.
Request와 마찬가지로 사용하려면 3)을 진행시켜야 한다.

3) Wrapping API views

이것엔 두 가지 방법이 있다.
1. @api_view : FBV용
2. APIView : CBV용

용도 및 장점

• DRF의 Request,Response 기능을 사용할 수 있게 해준다.
• Serializer를 호출하기 전에 발생할 수 있는 에러를 처리해준다.
  예를 들어,
  • 405 Method Not Allowed
  • ParseError
• Browsability. 브라우저에 Response를 볼 수 있도록 HTML 페이지를 랜더링해준다.

3) Adding format suffix

http://example.com/api/items/4.json 형식의 url 처리하는 추가 옵션 지정하는 방법. 이것은 필요시 공식 문서를 참고하자.

---

---

3. Class-based Views

---

1) Mixin

generics.GenericAPIVew에 원하는 메서드 Mixin을 추가하여 사용.
(1) queryset에 인스턴스 리스트를 모두 가져온다.
(2)serializer_class 를 명시해준다.
(3) 메서드 이름엔 HTTP 메서드이름을 사용하고, Mixin의 액션 메서드를 리턴하면 된다.
자세한 건 공식 홈페이지에 나와있는 코드를 보면 쉽게 알 수 있다.

하지만 Detail에도 queryset으로 모든 인스턴스를 가져오는 것은 비효율적이지 않나 싶다.

2) GENERICS

Mixins 상속문이 줄어들며, 메서드를 만들 필요도 없다. 1)의 (2)까지만 하면 끝이다.

---

---

4. Authentication & Permissions

---

새로 배운 기능이 많아서 다시 복습하며 정리할 필요가 있음.

---

---

5. Relationships & Hyperlinked APIs

---

reverse

from rest_framwork.reverse import reverse
기존의 url을 Response에 담는 역할을 한다.

@api_view(['GET'])
def api_root(request, format=None):
    return Response({
        'users': reverse('user_list', request=request, format=format),
        'snippets': reverse('snippet_list', request=request, format=format)
    })

Hyperlinking

To use a hyperlinked style between entities useHyperlinkedModelSerializer.

The HyperlinkedModelSerializer has the following differences from ModelSerializer:

• It does not include the id field by default.
• It includes a url field, using HyperlinkedIdentityField.
• Relationships use HyperlinkedRelatedField, instead of PrimaryKeyRelatedField.

Pagination

디폴트 버전

# settings.py

REST_FRAMEWORK = {
    'DEFAULT_PAGINATION_CLASS': 'rest_framework.pagination.PageNumerPagination',
    'PAGE_SIZE': 10
}

---

---

6. ViewSets & Routers

---

ViewSet

MIXIN 과 GENERICS가 HTTP 메서드를 메서드로 정의하고 이들이 액션 메서드를 리턴하는 방식을 썼만, ViewSet은 HTTP 메서드를 따로 정의하지 않는다. 액션 메서드 연결을 아예 url에서 actions 코드를 설정함으로써 연결되게 해놨다.

---