views.py

model, serializer, urlpattern 모두 중요한 요소이다.

특히 model은 데이터베이스의 기본 틀 역할을 하니 매우 중요하다고 할 수 있다.

그래도 결국엔 views.py의 view들이 없다면 model은 빈 깡통에 불과하다.

그래서 이번에는 views.py에 대해 정리해보려한다.

 

Class-Based-View(이하 CBV) vs Function-Base-View(이하 FBV)

처음에는 이 부분에 대한 협의없이 FBV로 회원가입과 로그인을 구현했다.

github 브랜치에 푸시를 했더니, BE부문을 같이 맡고 있는 uwoobeat님이 CBV를 사용하는 것이 좋지 않겠냐는 의견을 제시해주셨다.

여태껏 FBV로 작성해와서 CBV에는 익숙하지 않았다.

그러나, 제네릭뷰 등을 사용할 수 있다는 장점으로 설득하시니 넘어가지 않을 수 없었다.

처음에는 불편했지만, 코드를 작성하면 할수록 제네릭뷰의 편리함에 감탄했다.

처음에 불편함을 느낀 이유는 제네릭뷰를 사용하지 않았기 때문이다.

APIView만을 이용하여 코드를 짜다보니 같은 내용을 반복해서 작성해야했고, CBV의 장점을 충분히 활용하지 못했다.

이후, 공지 검색을 위한 NoticeSearchAPI를 만들 때는 제네릭뷰를 사용해보려고 노력했고, 그 덕에 검색된 결과를 목록으로 반환하는 것을 간단히 성공했다.

 

CreateAccountAPI

serializer = RegisterSerializer(data=request.data)
serializer.is_valid(raise_exception=True)
user = serializer.save()

_, token = AuthToken.objects.create(user)

사용자가 회원가입을 시도할 때는 유효성 검사를 거쳐 데이터베이스에 저장한다.

line1에서 입력을 serializer에 넘겨주면, serializer는 들어온 정보를 적절한 형태로 변환해준다.

이제 이 변환된 정보가 유효한지를 확인하는 is_valid()를 거쳐 save까지 마치면 토큰을 생성하는 단계이다.

사실 회원가입을 하는 단계에서 토큰 생성이 왜 필요한지는 모르겠다.

 

LoginAccountAPI

로그인을 하는 과정은 계정 생성 과정과 크게 다르지 않다.

유효성 검사를 통해 토큰을 발급한다.

한가지 다른 점이 있다면, 토큰의 활용이다.

여기서 생성된 토큰이 만료되기 전까지 사용자는 이를 이용하여 다른 페이지에 자유롭게 접속한다.

구글링을 정말 많이 한 부분이다.

request의 header에 토큰을 넣어서 인가를 해야하는 것은 알겠는데, 그래서 어떻게 넣는지를 잘 모르겠었다.

일단 나는 POSTMAN을 사용하여 request를 보냈는데, 방법은 아래와 같다.

key에 Auth까지만 입력해도 자동완성이 된다.

Value에는 “Token <token>”의 형식으로 넣어주면 된다.

 

NoticeSearchAPI

내가 유일하게 제네릭뷰를 이용하여 만든 APIView다.

검색 결과를 목록으로 보내줘야하기 때문에, ListModelMixin을 사용했다.

get_queryset 함수에서 검색결과를 찾는 부분만 구현을 했더니 알아서 목록의 형태로 반환해줬다.

이미 있는 걸 잘 활용해야한다는 말이 무슨 말인지 이해할 수 있게되었다.

 

이외

Response를 할 때 status지정을 굉장히 엉성하게 해뒀다.

뭐든지 try-except문에 넣어서 문제가 발생하면 except문을 통해 404_NOT_FOUND를 반환하게 해뒀다.