현재 글에서는 내가 느낀점을 간단하게 올린정도 밖에 안된다 만약 이 글을 읽고 공부를 하겠다 라는 생각을 가졌다면 당장 뒤로가기 버튼을 클릭하여 더 좋은 블로그 포스팅을 보기 바란다.
이번에 회사에 입사하게 되면서 DRF에 대해 공부를 했는데 알게된 사실들을 정리해보는 시간을 가질 것이다.
사전에 정의되여있는 것을 구차하게 나열하기 보다는 내가 공부하면서 이해하여 이런것이다. 라는식으로 정리를 할 것이다. 그러므로 틀린 사실이 있을 수 있으므로 다른 글도 충분히 보기를 바란다.
DRF
DRF란 Django REST Framework의 약자로 단순히 Django 프레임워크 환경에서 REST API를 설계하는 프레임워크를 칭한다.
API, REST API
API와 REST API에 차이에 대해 알아보자
우선 둘다 HPPT 통신규약을 이용하여 정보를 Request,Resporn받는 것으로 알고 있으며 성질은 매우 비슷하다고 생각을 한다. 그럼 어느부분에서 차이가 있을까? 데이터를 주고받는 형식에 차이가 있다.
api는 정형화 되어있지 않은 데이터 덩어리를 보낸다는 느낌이 드는 반면 REST API는 같은 데이터라도 json,xml형식을 이용하여 잘 정리 되어있는 물건을 받는 느낌이다. 예를 들어 우리가 서랍에 물건을 보관할때 정리는 신경쓰지않고 아무렇게나 넣어둔 다음 나중에 그 물건이 필요할 경우 찾게되면 굉장히 난잡하고 찾기 어렵다는 느낌을 받을 수 있다.
하지만 평소에 분류별로 정리정돈이 잘된 서랍에서 물건을 찾게된다면 알아보기도 쉽고 원하는 물건을 보다 빠르게 찾게 될 것이다 통신방식도 정해져있어 4가지로 [GET, POST, PUT, DELATE]로 나뉜다 이게 무슨 의미로 사용되는가 하니
[검색, 삽입, 수정, 삭제]로 해석이 된다
RESTful API
그렇다면 RESTful이란 것은 무엇을까 url을 설계를 하다보면 url문장이 더럽고 길게 설계가된다고 하면 "이건 RESTful하지 못해!"라는 말이 있다고 한다. 반대로 얘기하면 깔끔하며 알아보기쉬운 url이 RESTful이라고 칭하는 듯 하다 그리하여 깔끔하고 알아보기 쉬운 url을 만들기 위한 메뉴얼이 있는데 다음과 같다
1. 명사를 사용해라
내가 처음 게시판을 만들면서 api를 설계할때는 BoradInsert,BoardSelect 등 한글로 말하자면 "게시판삽입", "게시판검색"이라는 api가 설계되어 url에 띄워졌다. 이것을 명사를 사용한다.가 적용된다면 Board는 명사, insert,select는 동사가 되므로 동사를 빼게된다면 board만 url에 board만 남게 될 것이다. 원래 2개의 api였는데 동사를 빼게 되면 똑같은 이름의 api가 된다는 생각을 하였는데 api를 클래스 형태로 만들어라 그럼 해결된다.
예) 127.0.0.1:8000/Board/
2. 소문자를 사용해라
대문자가 껴있다면 소문자로 치환해라
예)127.0.0.1:8000/board/
3. 복수형을 사용해라
단수형이면 뒤에 s를 붙이던가..
예)127.0.0.1:8000/boards/
4. 구분자는 '-'를 사용해라(카멜케이스X)
필자는 변수를 작성하면 카멜케이스를 이용하거나(upDown), 공백대신 '_'를 사용하여 구분자 표시를 해주었는데 이런거 쓰지말고 '-'를 넣으라고 한다.
5.마지막 url에는 '/'를 포함하지 않는다
이건 진짜 몰랐네..
예)127.0.0.1:8000/boards
6. 파일확장자를 표지하지 않는다
아쉽게도 시험하고 싶은데 파일이 아직 없다.
이렇게 총 6가지가 RESTful한 api를 만드는데 필요한 규칙들이다.
Serializer
일반적인 Django환경에서 api를 만드는 경우 Model, View, Template, Url 크게 4개정도만 추가를 해주게 된다면 API를 만드는데 큰 어려움이 있지는 않을 것 이다. 하지만 DRF환경에서는 Model, View, Serializer, Url로 바뀌었다는 생각이 들었다. 우선 Template가 사라지게 되었는데 처음에 Template가 있다는 전재로 설계를 진행하였는데 도저히 template가 있는 상태로는 RESTful api를 설계가 힘들다고 느꼈는데 처음에는 단순히 "내가 아직 모자란게 많아 그렇겠지 구글선생님께 물어보면 나같은건 생각도 하지 못한 개쩌는 방법으로 이 문제를 해결해줄거야"라는 희망을 가지고 방법을 약 4시간동안 찾았지만 결국 해결책을 찾지 못한채로 여쭈어보아 Django프레임워크는 풀스택 프레임워크로 이용하였지만 DRF에서는 프론트엔드 서버를 따로 동작시킨다는 말을 듣게 되었다. 그렇다면 프론트부분이 사라졌는데 새롭게 생긴 이 Serializer는 대체 무엇일까? db에서 가져온 오브젝트를 json이나 xml로 변환해주는 역할을 맡고있다.
#models.py
class Likeability(models.Model):
npc=models.OneToOneField(Npc, on_delete=models.CASCADE)
tear=models.ForeignKey(Tear,on_delete=models.CASCADE)#serializers.py
from rest_framework import serializers
class LikeabilitySerializer(serializers.HyperlinkedModelSerializer):
class Meta:
model=Likeability
fields='__all__'
View, ViewSet
view설계도 편하다고 생각이 되는데 기존에 crud 설계를 할때는 pk값을 이용해서 object를 찾고 만약 수정이라도 해야된다면 값을 바꾸어 다시 저장하는 식으로 진행이 되었다면 DRF는 ViewSet을 상속받아 이용하여 단순 crud를 구현할수 있다.
이 ViewSet을 이용한다면 무려 단 3줄만으로 구현이 가능하다 이말이다.
#views.py
from rest_framework import viewsets
class LikeabilityViewSet(viewsets.ModelViewSet):
queryset = Likeability.objects.all()
serializer_class = LikeabilitySerializer
Url, Routing
DRF에는 획기적은 url매핑방식으 있는데 그 이름하야 바로 Routing 기능 되시겠다.
#urls.py
from django.urls import include, path
from .views import *
from rest_framework import routers
router = routers.DefaultRouter()
router.register(r'gauges',LikeabilityViewSet)
urlpatterns = [
path('',include(router.urls)),
]여기서 8줄에 router.register(r'gauges',LikeabilityViewSet) 만 입맛대로 바꾸어준다면 pk를 이용한 디테일한 url까지 자동으로 만들어주는 놀라운 기술이다.
현재 글에서는 내가 느낀점을 간단하게 올린정도 밖에 안된다 만약 이 글을 읽고 공부를 하겠다 라는 생각을 가졌다면 당장 뒤로가기 버튼을 클릭하여 더 좋은 블로그 포스팅을 보기 바란다.