DRF는 과연 무엇인지! 우리는 왜 DRF를 쓰고 있는 지를 알아봅시다~
DRF는 Django Rest Framework
의 약자로
- Django 에서 사용할 수 있는
- RESTful 한 API 개발을 도와주는
- Framework 입니다
잠깐잠깐!! RESTful한 API 개발? 처음 들어봤는데?
자, 다시~
REpresentational State Transfer의 약자
즉, 자원이나 정보의 상태(State)를 전달(Transfer)하는 표현(Representational)입니다.
쉽게 말해, 개발자들이 웹에서 정보를 보낼 때 동일한 방식으로 보내자~
라고 합의한 것 입니다.
REST한 조건을 만족하는 API를 RESTful하다
라고 합니다.
여기엔 여러 가지 규칙이 있지만, 크게 두가지만 알아두셔도 큰 문제는 없습니다.
URI는 쉽게 말하면 https://www.naver.com/어쩌구저쩌구
형식의 주소를 말합니다.
URI의 자세한 정의는 다루지 않고 규칙에 대해 말해볼게요.
- 자원의 명시
- URI는 자원(resource)을 명확하게 표현해야 합니다.
- 동사보다는 명사를, 대문자보다는 소문자를, 단수형보다는 복수형을 사용합니다.
- 예)
/users
,/products
,/orders
- 계층구조
- 자원 간의 관계를 표현하기 위해 계층 구조를 이용합니다.
- 계층 구조는
/
를 사용하여 표현할 수 있습니다.- 마지막에 슬래시
/
를 포함하지 않습니다.- 예 )
/users/123/orders
,/products/456/reviews
- 언더바
_
대신 하이픈-
을 사용한다
- 가독성을 위해 긴 Path를 표현하는 단어는 하이픈
-
으로 구분하는 것이 좋습니다.- 폰트에 따라 언더바 문자는 부분적으로 가려지거나 숨겨질 수 있기 때문입니다.
- 나쁜 예 )
/password_reset
- 좋은 예 )
/password-reset
- 파일확장자는 URI에 포함하지 않는다
- 나쁜 예 )
/blog/34/photo.jpg
- 좋은 예 )
/blog/34/photo
- 행위를 포함하지 않는다
- REST API에서는 동작을 HTTP Method로 표현하므로, URI에 동작을 포함하지 않습니다.
- HTTP Method는 아래에서 다룰 예정입니다.
- 나쁜 예 )
/delete-blog/1
- 좋은 예 )
/blog/1
잠깐만여,, 그럼 blog를 지우고 싶을 때와 생성하고 싶을 때는 같은 URI를 쓰나요?
맞습니다! 하지만, 같은 URI를 쓰더라도 다른 HTTP Method
를 통해 전달하여 다른 동작을 수행합니다.
어떤 데이터를 담느냐! 만큼 중요한 게 어떻게 데이터를 주느냐!
입니다.
데이터를 주는 기본 동작은 4가지가 있는데, Create, Read, Update, Delete 입니다.
이를 HTTP Method에서는 아래의 5가지 방법으로 구현합니다.
- POST (Create)
- 서버에 새로운 정보를 생성합니다.
- 일반적으로 서버에서 생성된 새 리소스의 ID를 반환합니다.
- GET (Read)
- 서버에서 정보를 조회하거나 읽어오는 데 사용됩니다.
- GET 요청은 데이터를 변경하지 않으며, 오직 데이터를 가져오기만 합니다.
- PUT (Update)
- 서버에 있는 정보를 새로운 내용으로 완전히 대체합니다.
- PUT 요청은 리소스의 모든 속성을 새로운 값으로 변경합니다.
- PATCH (Update)
- 서버에 있는 정보의 일부 속성만 수정합니다.
- PUT과 달리 PATCH 요청은 리소스의 일부분만 변경합니다.
- DELETE (Delete)
- 서버에서 특정 정보를 삭제합니다.
- DELETE 요청은 리소스를 영구적으로 삭제합니다.
따라서, blog를 지우고 싶을 때는
http://likelion.com/blog/1
이라는 URI를 DELETE
라는 HTTP Method로 요청하면 되는 것입니다.
정확한 URI를 올바른 HTTP Method로 보내는 것이 RESTful한 API의 핵심입니다.
앞서 말했듯이 RESTful API는 정보를 전달하는 방법에 대한 약속 입니다.
우편의 예를 들어보죠.
우편을 보낼 때 송장처럼 물건을 보낼 때 필요한 여러 가지 정보들이 동일한 방식으로 적혀져 있으면 보내는 사람이나 받는 사람이나 편하겠죠?
Rest API도 이처럼 인터넷 상에서 정보를 주고받을 때 일종의 송장 역할을 한다고 생각하시면 됩니다!
음... 뭐... 알겠습니다..
잠시만요! 저희는 forms.py랑 views.py를 통해 프론트와 정보를 주고받지 않았나요?
- 기본적으로 Django는 데이터베이스를
QuerySet
이라는 타입으로 처리합니다.
- 우리가 기존에 쓰던
forms.py
에서는 이QuerySet
타입의 데이터베이스를
HTML Form
으로 포장하여 장고 내부의 HTML과 소통하도록 해줍니다.
- 이 때, 장고는
QuerySet
타입의 데이터베이스를 그대로 사용하도록 만들어져있습니다.
- 하지만, 장고 내부에서 프론트엔드 개발을 하지 않을 때
(예를 들어,React
같은 다른 프론트엔드 프레임워크와 정보를 주고받을 때)는QuerySet
타입을 피해야합니다.QuerySet
은 Django에서만 사용되는 특수한 데이터 구조이기 때문이죠.
- 이에 우리는 QuerySet 타입의 데이터베이스를
Restful한
다른 형식으로 변환하는 작업이 필요하고, 이 작업을 직렬화(Serialize) 라고 합니다. 주로JSON
형식으로 직렬화를 시키며, 이 외에도XML
,YAML
등의 표준화된 데이터 형식이 있습니다.
- 저희는 주로 Javascript를 쓰는 프론트엔드 프레임워크와 협업하기 때문에, Javascript의 표준 격이라고 할 수 있는
JSON
형식을 주로 사용합니다.
데이터 형식에 대해 간단히 알아봅시다~!
이런 데이터를 만들고 싶다고 가정합시다
이름: Taeho Yoon
나이: 25
이메일: taehoyoon@example.com
관심사: ["programming", "music", "travel"]
이 데이터를 여러 데이터 형식으로 나타내볼게요~
{
"name": "Taeho Yoon",
"age": 25,
"email": "taehoyoon@example.com",
"interests": ["programming", "music", "travel"]
}
파이썬 딕셔너리랑 비슷하게 생겼죠?? 하지만 엄연히 다르답니다
<person>
<name>Taeho Yoon</name>
<age>25</age>
<email>taehoyoon@example.com</email>
<interests>
<interest>programming</interest>
<interest>music</interest>
<interest>travel</interest>
</interests>
</person>
name: Taeho Yoon
age: 25
email: taehoyoon@example.com
interests:
- programming
- music
- travel