chapter4 p.103 DRF 컨셉 익히기

모델

영진닷컴 사이트에 있는 도서 정보를 기반을 모델을 만들어보겠습니다. 

 

모델을 작성하였으니 마이그레이션 해야겠죠 

 

시리얼라이저

모델을 만들고, 뷰를 작성하기 전, 바로 이 단계에서 시리얼라이저를 만들겠습니다. 

 

시리얼라이저는 파이썬 모델 데이터를 JSON으로 바꿔주는 변환기이기 때문에 

모델 데이터의 어떤 속성을 JSON에 넣어줄지 선언을 해줘야 합니다.

 

JSON에다가 모델의 모든 속성을 넣지 않을 수도 있으니까요,

외부로 공개되는 API의 경우 더더욱 그런 경우가 많습니다. 

그래서 시리얼라이저에도 필드를 선언해 주어야 합니다. 

 

create()나 update()는 나중에 POST요청으로 들어온 데이터를 다시 파이썬 모델 형태로

역직렬화하여 데이터베이스에 집어넣을 때 사용되는 함수입니다. 

 

암튼 이런 코드를 작성하면 같은 내용이 반복되고 코드가 길다는 느낌이 들지요?

그래서 우리는 더 나은 대안인 serializers.ModelSerializer를 사용할 것입니다. 

 

엄청 간단해졌죠?

ModelSerializer는 이름에서 알 수 있듯이 모델의 내용을 기반으로 동작하는 시리얼라이저입니다. 

이를 통해 코드의 중복을 줄일 수 있고, 필드 선언도 모델에서 이미 했으니 시리얼라이저에서는 간단하게 작업을 마칠 수 있습니다. 

 

이제 뷰를 작성할 차례입니다. 

뷰는 개념 설명과 함께 진행하겠습니다. 

 

 

4.3.2 DRF FBV, CBV, API View

DRF 뿐만 아니라 장고에서는 크게 두가지 유형으로 뷰를 개발할 수 있습니다.

함수기반 뷰 -> FBV

클래스 기반 뷰 -> CBV

 

이 둘은 그저 뷰를 작성할 때 함수로 작성했는지 클래스로 작성했는지의 차이일뿐 기능 상 차이는 없습니다. 

그렇다면, 우리가 그동안 작성했던 뷰는 모두 FBV(함수기반 뷰)겠네요!

 

이 둘을 공통적으로 도와주는 친구가 있습니다. 바로 APIView라는 것입니다. 

 

 

---

 

 

APIView는 여러 가지 요청의 유형에 대해 동작할 수 있도록 도와줍니다. 

 

클래스형 뷰에서는 뷰를 만들때 APIView라는 클래스를 상속받는 클래스의 형태로 생성합니다. 

 

 

이번 단원은 DRF를 가볍게 익혀보는 것에 있으니, 도서 정보 API를 빠르게 완성해봅시다!

어느 형태의 뷰로 작성해도 상관 없지만, 이해를 위해 두 가지 방법 모두로 똑같이 작성해보겠습니다. 

 

도서 정보 API는 앞서 살펴봤던 것처럼

전체 도서 정보를 가져오는 API(GET/book/)와 

bid에 해당하는 도서 1권의 정보를 가져오는 API(GET/book/1/)가 있습니다. 

또한 도서 정보를 등록하는 API(POST/book/)까지 있습니다. 

 

여기서 하나 기억하고 넘어갈 것은

전체 도서 정보를 가져오는 API와

도서 정보를 등록하는 API의 주소가 동일하게 '/book/' 이라는 것입니다.

 

그럼 코드로 작성해봅시다! 먼저 함수형뷰 (FBV)로 작성한 코드입니다. 

 

일단 /book/ 주소를 사용할 두 API에 대한 처리는 booksAPI()라는 함수에서 한 번에 처리하고 있습니다. 

데코레이터로 GET, POST를 함께 처리할 수 있도록 설정해주었고, 

조건문을 통해 해당 요청이 GET인지 POST인지에 따라 다르게 처리하고 있습니다. 

 

 

GET 요청은 

도서 전체 정보를 가져오므로 모델로부터 데이터를 가져와 시리얼라이저에 집어넣어 직렬화를 하고

그렇게 가공된 데이터를 결과로 응답합니다. 

데이터를 잘 가져왔으면 200 메시지를 보냅니다. 

 

POST 요청에 대해서는

오히려 요청으로 들어온 데이터를 역직렬화하여 모델에 집어넣어야 하므로 먼저 시리얼라이저에 request.data를 넣습니다. 

 

다음으로는 

bookAPI() 함수입니다. 여기서는 특정 bid의 책 데이터를 가져옵니다. 

 

 

4.3.3 도서 정보 API 마무리 하기

이제 URL을 연결하여 도서 정보 API 예제를 완성하겠습니다. 

 

뷰를 모두 URL에 연결해 보겠습니다. 

example 앱의 urls.py를 열어 아래 내용을 작성합니다. 

 

 

실행해보니 위처럼 나오네요, 

아직 도서 데이터를 입력하지 않았기 때문에 빈 결과가 도착하고, 이 주소로 POST 요청을 보낼 수 있기 때문에 

POST 요청을 위한 폼이 나타납니다. 

그럼 POST 기능도 한 번 활용해보겠습니다. 

 

 

위와 같은 JSON 형식의 데이터를 넣고

오른쪽 하단의 POST 버튼을 누르겠습니다. 

그러면 ? 

 

POST 요청을 보내고 처리가 완료된 후에 다시 /fbv/books/로 GET요청을 보내게 된 화면입니다. 

아까는 데이터가 없었는데, 방금 우리가 데이터를 POST로 추가하였기 때문에 다시 GET 요청 화면에서 데이터가 보이게 된 것입니다. 

이런 식으로 데이터를 여러개 추가할 수 있습니다. 

 

이번에는 bid값으로 책을 찾아보겠습니다. 

주소창에 아래와 같이 입력합니다. 

http://127.0.0.1:8000/example/fbv/book/1/

 

 

위 주소로 들어가니 bid가 1인 도서의 정보가 나타납니다. 

우리의 함수형 뷰 API가 모두 정상 작동하는 것을 확인하였습니다. 

 

그동안 함수형 뷰와 클래스형 뷰에 대해 배워보았습니다. 

이들을 시리얼라이저와 연결하고, 시리얼라이저는 모델과 연결되어 잘 작동하는 것까지 확인하였습니다. 

 

이 들 모두 결국엔 각 request의 method에 따라 처리를 할 수 있도록 작성됩니다. 

이때 같은 URL을 쓰는 메소드들은 하나의 혹은 클래스로 묶여 그대로 URL에 연결됩니다. 

 

이제 Django REST Framework의 기초 내용은 모두 배웠습니다. 

아주 간단하게나마 우리는 API 서버을 만들 수 있었습니다. 

 

이제부터 아래에서 배울 내용은 알면 아주 유용한 DRF의 기능들입니다. 

DRF의 개발 절차를 한 번 더 복습하고 넘어가겠습니다. 

 

Model -> Serializers -> Views -> Urls(다시 Serializers)

 

DRF의 기본 페이지로 API 테스트를 하는 것도 나쁘지는 않지만, 어디까지나 브라우저를 활용하는 방식이라 불편할 수 있음

API테스트를 위한 전용 프로그램이 몇가지 있는데, 

Insomnia라는 무료 툴 추천,

 

+버튼을 클릭하고 New Folder를 클릭합니다. 

 

폴더를 다음과 같이 생성합니다. 

New Request를 선택했습니다. 

요청의 이름과 메소드를 선택하여 생성할 수 있습니다. 

일단 GET요청을 만들 것이고,

빈칸으로 두고 생성하면 요청의 주소가 이름이 된다고 적혀있으니 빈 칸으로 만듭시다. 

 

맨 위에 주소를 입력하는 곳에 우리의 API 주소를 입력합니다. 

 

http://127.0.0.1:8000/example/fbv/books/

 

send를 누르면 200 OK와 함께 우리의 도서 데이터가 잘 도착합니다. 

이번엔 POST 요청을 해볼까요?

 

 

 

POST로 설정하고 body의 양식을 JSON으로 설정합니다. 

앞에 입력한것과 같은 JSON을 입력합니다.

 

send를 눌러 실행하면?

실행결과 201 created가 나오며 잘 생성된 것을 볼 수 있습니다. 

다시 GET을 실행해 잘 들어갔는 지 확인해 보면?

 

 

4.4 Django REST Framework 심화 개념 보충하기

4.4.1 DRF의 다양한 뷰

DRF에서 작성하는 뷰는 크게 함수형 뷰와 클래스형 뷰로 나눌 수 있었습니다. 

 

클라이언트 측에서 우리 API로 요청을 보낼 때에는 URL과 Method를 조합하여 요청을 보내는데,

이때 같은 URL 내의 여러 Method를 처리하는 방법으로 함수형과 클래스형이 구분되었습니다. 

 

결국 같은 일을 하는 두가지 방법이라는 뜻입니다. 

 

그렇다면 URL과 Method의 조합 은 몇가지 정도 있을까요?

5가지 정도 나옵니다. 

 

이 정도면 모든 요청에 대한 처리를 해줄 것 같다는 생각이 듭니다. 

각 URL 옆에 붙은 단어들이 각 기능별 닉네임이라고 생각하면 됩니다. 

 

어떤 모델에 대해 retrieve를 한다고 하면 우리는 그 모델의 1개 개체 정보를 가져온다고 생각하면 되겠습니다. 

DRF로 API를 개발할 때 만들어야 하는 기능은 위 5가지가 전부입니다. 

이 5가지 기능을 만드는 방법은 함수형 뷰와 클래스형 뷰가 있었습니다. 

 

이는 모델 API 만들기에서 공통적으로 쓰이는 기능이므로 개발자들은 이를 최대한 편하고 쉽게 만들고자 하였습니다.

어떤 과정을 거쳐 발전하였는지 mixins, generics, Viewset 까지 하나하나 배워봅시다. 

 

 

4.4.2 DRF mixins

mixins 는 APIView에서 request의 method마다 시리얼라이저 코드를 작성하는 것을 줄이기 위해

클래스 레벨에서 시리얼라이저를 등록하고 있습니다. 

각 method에는 시리얼라이저 코드를 작성하는 대신

각 method별 mixin에 연결하여 사용하기만 하면 됩니다. 

 

4.4.3 DRF generics

mixins 방법에서 사용할 mixins를 상속받는데 한 번에 2~3개 씩 상속을 받아야 하니 이게 너무 번거로운 것 

 

 

4.4.4 DRF Viewset & Router

generics 만으로 충분히 코드를 간소화 하였지만, 더 줄일 수 있는 부분이 있습니다. 

queryset이나 serializer_class 부분이 겹치게 되었습니다. 

하나의 클래스로 하나의 모델을 전부 처리해줄 수 있으면 겹치는 부분이 없어질 것입니다. 

Viewset에서는 그러한 문제를 해결할 수 있습니다. 

 

 

 

지금까지 DRF의 여러 기능들을 배워보았습니다. 우리가 그동안 배워보았습니다. 

다음 장부터 만들 프로젝트는 꽤 큰 프로젝트로, 실제 백엔드 개발자로서 프론트엔드와

연동하는 과정까지 다루는 방대한 내용을 포함한 프로젝트 입니다. 

 

 

 

 

 

 

 

 

백엔드를 위한 Django REST Framework with 파이썬

 

 

 

"이 포스팅은 쿠팡 파트너스 활동의 일환으로, 이에 따른 일정액의 수수료를 제공받습니다."