Django_14) Django REST Framework

현재까지 Django를 학습하면서 우리는 그럴듯한 기능을 가진 프로젝트를 구현해보았다. 그러나 한 가지 의문이 든다. 우리는 처음을 기억해보면 분명 Django는 Backend Framework이었지만, HTML을 렌더링하며 제공하고 있었다. 물론 html, css를 입힐 수 있지만 이는 Frontend의 역할이고 Django는 이에 특화되어있지 않으므로 이후 Vue를 배워볼 예정이다. 그래서 우리는 Back의 역할을 DB를 관리하여 Front에 명시적이고 정확하게 전달하는 것들으로 알아두면 좋을 것이다.

API(Application Programming Interface)

애플리케이션과 프로그래밍으로 소통하는 방법
클라이언트 - 서버 처럼 서로 다른 프로그램에서 요청과 응답을 받을 수 있도록 만든 체계

REST(Representational State Transfer)

API Server를 개발하기 위한 일종의 소프트웨어 설계 방법론(약속 - 규칙 X)

REST API

REST라는 설계 디자인 약속을 지켜 구현한 API

REST에서 자원을 정의하고 주소를 지정하는 방법

1. 자원의 식별 -> URI

   URI

   인터넷에서 리소스(자원)를 식별하는 문자열 - 가장 일반적인 URI는 웹 주소인 URL
   URL : 웹에서 주어진 리소스의 주소, 네트워크 상 리소스가 어디 있는지 알려주기 위한 약속
   

2. 자원의 행위 -> HTTP Methods

   HTTP Request Methods

   1. GET(Read에 해당)

      서버에 리소스의 표현을 요청
      GET을 사용하는 요청은 데이터만 검색해야 함

   2. POST(Create에 해당)

      데이터를 지정된 리소스에 제출
      서버의 상태를 변경

   3. PUT(Update에 해당)

      요청한 주소의 리소스를 수정

   4. DELETE

      지정된 리소스를 삭제

   HTTP response status codes

   특정 HTTP 요청이 성공적으로 완료 되었는지 여부를 나타냄
   

3. 자원의 표현 -> JSON 데이터, 궁극적으로 표현되는 데이터 결과물

   지금까지 Django 서버는 사용자에게 페이지(html)만 응답하고 있었다.
   하지만 서버가 응답할 수 있는 것은 페이지 뿐만 아니라 다양한 데이터 타입을 응답할 수 있다.
   REST API는 이 중에서도 JSON 타입으로 응답하는 것을 권장한다.
   
   
   
   
   도입부에서 했던 이야기를 정리한 사진을 보며 우리의 방향성은 요청을 받은 것을 Front까지 JSON 파일로 잘 보내는 것으로 설정하자.

사전 준비

1. pip install, app등록(rest_framework), 필요하다면 loaddata
2. URL의 데이터를 우리가 쓸 python 언어로 쓸 수 있도록 변환되는지 확인(파이썬 파일 만들고)

DRF

Django에서 Restful API 서버를 쉽게 구축할 수 있도록 도와주는 오픈소스 라이브러리

Serialization(직렬화)

여러 시스템에서 활용하기 위해 데이터 구조나 객체 상태를 나중에 재구성할 수 있는 포맷으로 변환하는 과정
어떠한 언어나 환경에서도 나중에 다시 쉽게 사용할 수 있는 포맷으로 변환하는 과정

자 이제, Article의 CRUD를 html파일 없이 JSON파일로 보내어 구현해보자.
RESTful 하기 위해 자원의 행위에 따라 url을 겹쳐 사용할 수 있기 때문에 웹에서 확인하기 어렵기 때문에 Postman을 사용하자.

Postman은 API를 구축하고 사용하기 위한 플랫폼으로, API를 빠르게 만들 수 있는 여러 도구 및 기능을 제공한다.

HTTP requests method에서의 article_pk의 필요성에 따라 url을 설계하자.

1. GET - List (전체 게시물 조회)

1. serialize 하기
   
   모델폼과 유사한 serializers를 사용하여 json파일로 반환하도록 하자.

ModelSerializer

Django 모델과 연결된 Serializer 클래스

2. url / view 작성
   
   
   url 주소는 RESTful 하게 간결해졌다.(행위가 빠짐)
   view 함수를 같이 들여다보자. 먼저 데코레이터가 없으면 DRF는 코드를 읽지 않고 오류를 반환한다. 그래서 어떤 방식인지를 미리 정하고 적어줘야한다. 그 다음 주목할 것은
   ArticleListSerializer(articles, many=True)인데, 첫번째 인자는 데이터를 두번째 인자에는 단일 객체가 아니면 many=True로 바꿔줘야한다. 단일 객체면 생략 가능
   마지막 return Response(serializer.data)이다. Response와 .data를 통해 serialize된 데이터가 json 파일을 보내게 된다. 이를 Postman으로 확인해보자.

이전 view 함수와의 비교

과거 : HTML에 출력되도록 페이지와 함께 응답했던 view 함수
현재 : JSON 데이터로 serialization하여 페이지 없이 응답하는 현재의 view 함수

2. GET - Detail (단일 게시글 조회)

1. serialize 하기
   

2. url / view 작성
   
   
   url 주소는 RESTful 하게 간결해졌다.(행위가 빠짐)
   view 함수를 보면, 데코레이터가 있고, article_pk가 필요하다.
   단일 객체를 조회하고 이를 serialize 하는데, 이때 many 속성은 빠지게 된다.
   이 또한 Postman으로 확인해보길 바란다.

3. POST - Create (게시글 생성)

게시글 데이터를 생성하기
데이터 생성에 성공 -> 201 Created 응답
데이터 생성에 실패 -> 400 Bad request 응답

method에 의해 분기처리가 되므로 url을 수정하거나 추가하지 않는다.
데코레이터에 POST를 추가해주고 명시성을 위해 else가 아닌 elif를 사용한다.
그럼 elif 아래 구문만 같이 분석해보자.
POST 요청에는 request가 데이터를 보낼 것이기 때문에
ArticleSerializer(data=request.data)가 들어갈 것이다.
이때 is_valid()는 Django와 동일한 역할을 하며, 이를 DB에 저장한다.
유효성 검사를 통과했다면 그 데이터를 보여주면서 201CREATED를 응답하고
실패했다면 에러를 보여주면서 400BADREQUEST를 응답하게 된다. 이 방법들으 코드를 참고하기 바란다.

4. DELETE(게시글 삭제)

게시글 데이터 삭제하기
데이터 삭제에 성공했을 경우 204 No Content응답

기존의 Detail 기능(article_pk가 필요한 곳)에다가
method에 의해 분기처리가 되므로 url을 수정하거나 추가하지 않는다.
데코레이터에 DELETE를 추가해준다.
삭제는 delete() 메서드를 사용하면 된다.
삭제 후 따로 보여줄 데이터가 없기 때문에 status인자만 넣어주면 된다.

5. PUT - Update(게시글 수정)

게시글 데이터 수정하기
수정에 성공했을 경우 200 OK 응답(자동)

<참고> raise_exception

is_valid()는 유효성 검사 오류가 있는 경우 ValidationError 여외를 발생시키는 선택적 raise_exception 인자를 사용할 수 있음
DRF에서 제공하는 기본 예외 처리기에 의해 자동으로 처리되며 기본적으로 HTTP 400 응답을 반환

Article의 기능을 html 없이 DRF로 구현해보았다.
Comment 기능(N:1 관계)도 진행해보자.

1. 모델 만들기

2. HTTP request method에 따라 URL 구성 설계

3. GET - List(Read - 댓글 전체 조회)

1. CommentSerializer 정의
   

2. url 작성
   

3. view 함수 작성
   

4. GET - Detail(Read - 댓글 단일 조회)

1. url / view 작성
   

5. POST(Create - 댓글 작성)

1. url / view 작성
   

2. serializer의 인스턴스 save() 메서드는 저장하는 과정에서 추가 데이터를 받을 수 있음
   
   -> 상태코드 400 응답(오류) - 데이터를 전송하는 시점에 유효성 검사를 통과하지 못하기 때문에
   아래 데이터를 받는 코드까지 도달을 못함 -> commit=False 하고 싶지만 이것은 ModelForm의 인스턴스 save() 메서드의 것이고 serializer의 것과는 다르다. -> 유효성 검사를 제외시키는 방법인 읽기 전용 필드에 넣자.

3. 읽기 전용 필드
   

6. DELETE & PUT (Delete & Update - 댓글 삭제 및 수정)

1. view 작성
   

응답 데이터 재구성

만약 단일 댓글을 조회하는 상황에 있을 때 article field에는 ForiegnKey가 들어오게 되는데, 만약 제목을 알고 싶다면 다시 그 번호를 받아서 조회하고 시리얼라이즈하고 하는 큰 과정을 돌게 된다. 애초에 난 제목을 알고 싶어 라고 설계를 했다고 할 때, 우리는 응답받는 데이터를 원하는 대로 재구성하고 싶다. 그러한 방법을 알아보자.

댓글 조회 시 게시글 번호만 제공하지 않고 '제목'까지 제공하기

필요한 데이터를 만들기 위한 Serializer는 내부에서 추가 선언 가능

역참조 데이터 구성

단일 게시글 조회 시 '해당 게시글에 작성된 댓글 목록' 함께 응답

단일 게시글 조회 시 '해당 게시글에 작성된 댓글 개수' 함께 응답

여기서의 'source'는 필드를 채우는 데 사용할 속성의 이름이 들어가고, 점 표기법을 사용하여 속성을 탐색할 수 있음. 그리고 read_only를 왜 여기서 지정하지? 밑에 메타에서 필드로 설정하면 될 것 같지만 override 한 것은 위에서 설정해야함

<주의>
1. 특정 필드를 override 혹은 추가한 경우 read_only_fields는 동작하지 않음
2. 해당 필드의 read_only 키워드 인자로 작성해야함

API 문서화

OpenAPI Specification(OAS)

RESTful API를 설명하고 시각화하는 표준화된 방법
API에 대한 세부사항을 기술할 수 있는 공식 표준

OAS 기반 API에 대한 문서를 생성하는데 도움을 주는 오픈소스 프레임워크 2가지
Swagger와 Redoc가 있으니 둘 다 확인해보자.

1. drf-spectacular 라이브러리 설정
   
   
   

2. swagger 확인
   

3. redoc 확인
   

<참고> get_object_or_404() / get_list_or_404()

모델 manager objects에서 get()을 호출하지만, 해당 객체가 없을 땐 기존 DoesNotExist 에러 대신 HTTP404를 raise한다.
-> 기존의 에러가 발생하면 서버 문제처럼 500 코드를 반환하지만 유저가 잘못된 인덱스로 조회 한 것은 404코드를 반환하는 것이 바람직하다.