[GDSC 프로젝트 트랙] 2. 맡기 CRUD API 구현 & 배포

API 명세 논의

24년 1월 8일, 사당 스타벅스에 모여 회의를 진행했다.

내가 작성한 명세서를 토대로 더 추가해야할 API 가 있는지, API 에서는 어떤 형식의 데이터를 주고 받아야 하는지를 논의하였다.

 

논의 결과 아래와 같은 형태로 데이터를 주고 받게 되었다.

{
   "start_time": 1100,
   "date": "20240115",
   "child_age": 2013,
   "rating": 4.2,
   "address": "서울시 마포구 와우산로 70 홍익대학교 T동 702",
   "end_time": 2000,
   "email": "test2@example.com",
   "status": "waiting",
   "gender": "f",
   "id": "test2@example.com"
}

 

이걸 논의하면서 프로젝트 기획의 디테일한 부분을 고민할 수 있었다.

 

예를 들면 처음에는 이 형식에 '요일' 정보도 포함되어 있었는데, 이 요일 정보를 보고 '정기적으로 매주 맡겠다는 데이터가 되나?' 하는 생각을 했었다가, 그냥 특정 날짜에 맡는데 그 날짜의 요일을 표시하는 것 뿐이었다.

특정 날짜로부터 요일 정보를 가져오는 것은 프론트에서 할 수 있다고 해서 요일 데이터는 삭제하기로 했다.

 

또, 이 데이터는 "나는 이런 아이를, 어떤 날, 어떤 시간에 맡고 싶어요" 를 의미하는 데이터인데, 현재 데이터는 아이의 나이가 특정 나이로 정해져 있다. (child_age)

 

그런데 프로젝트를 진행하면서 '몇살부터 몇살까지 범위로 아이를 맡고 싶을 수도 있지 않을까?' 하는 제안을 팀원이 남겼고, 이에 모두 동의해서 데이터 형식을 나이 범위 값을 정하는 형태로 바꾸기로 하였다.

 

1월 8일부터 1월 14일까지 일주일간 나는 아래 API를 작성하였다.

 

아이를 맡겠다는 데이터를 생성, 수정, 조회, 리스트 조회 하는 API 이다.

삭제를 만들지 않은 이유는, 프로젝트 기획상, 모든 유저는 아이를 맡겠다는 데이터를 반드시 생성해야 했기 때문이다.

 

맡기 데이터의 status 변경 API 논의

아이를 맡겠다는 데이터 리스트를 보고, 아이를 맡길 사람은 리스트에서 원하는 '맡기' 데이터를 선택해 아이를 맡길 수 있다.

따라서 각 데이터는 '아직 아이가 맡겨지지 않은 상태' , '아이 맡기가 예약된 상태', '아이 맡기가 완료된 상태' 를 가진다.

 

그런데 현재 '맡기 데이터를 수정' 하는 API는 맡기 데이터를 생성한 사용자가, 이를 수정하려고 할 때 사용하는 API 로 의도를 잡았다. 그래서 이 상태를 변경하고자 할 때 PATCH /care 를 사용하는 것은 옳지 않다고 생각하여 1월 15일 회의를 진행한 뒤  status 변경을 위한 별도 API를 만들었다.

 

POST 는 새로운 데이터를 '생성' 하며, 여러번 반복실행하는 경우, 여러개의 중복 데이터가 생성되는 결과를 예상하는 메서드라고 공부하여, HTTP 메서드는 PUT 으로 결정하였다.

PUT은 데이터를 생성/수정 하는 Method 로, 여러번 반복실행하면 데이터를 한번만 생성하고, 이후에는 수정하는 결과를 예상하는 메서드라고 한다.

 

Care API 작성

care 라고 하는 앱을 새로 만들어 뷰 함수를 작성하였다.

 

DB에서 데이터를 가져온 뒤, 해당 데이터를 시리얼라이저에 넣어 응답할 형식에 맞춤과 동시에 데이터의 형식도 맞춘다.

나는 DB에서 데이터를 가져오는 코드를 작성하였고, 다른 백엔드 팀원은 가져온 데이터를 응답 형태에 맞게 바꾸는 시리얼라이저 코드를 작성하였다.

 

이 구조는 https://github.com/saadmk11/django-todo 이 프로젝트 구성을 참고하였다.

 

단일 care 데이터를 가져오는 API 이다.

 

맡기 데이터는 로그인된 유저 하나당 하나의 데이터만 생성할 수 있도록 하는 정책을 세웠다.

그래서 현재 로그인된 유저의 이메일을 PK 로 하는 맡기 데이터를 생성하도록 코드를 작성하였다.

 

그러나 아직 로그인 기능이 없어, 현재 유저를 식별할 수 없기에 위와같이 하드코딩으로 이메일을 설정하였다.

 

데이터 수정코드도 데이터 생성코드와 비슷하게 작성하였다.

 

장고의 장점은 모델과 제네릭 뷰를 이용해 이런 기본적인 CURD 기능을 짧은 코드로 작성하는데 있는데, 파이어베이스 기반 DB가 NoSQL 이라 그런지, 장고 모델과 연동하는 라이브러리가 없어서 (하나 있는데, 2020년 이후 갱신이 없으며 에러가 나서 적용할 수 없었다.) 이렇게 구현하게 되었다.

 

이렇게 구현하니 장고 프레임워크의 장점을 제대로 살리지 못하는 것 같아 아쉬운 점이 있다.

 

맡기 데이터의 status 를 변경하는 API 코드이다.

이상한 status 값이 저장되지 않도록 예외처리를 해주었다.

 

API 서버 배포

원래는 서버 배포 없이, 프론트는 직접 백엔드 프로젝트를 로컬에서 실행시킨뒤 테스트를 진행했었다.

그런데 파이어베이스 연동이 들어가면서 여러가지 설정과 라이브러리 추가가 필요했다.

나는 .env 를 사용해 파이어베이스 연동 설정값을 관리했는데, 내가 공유한 .env 파일의 개행문자가 맥에서 다르게 인식되는 문제로 프론트가 직접 개발환경 세팅을 하는데 문제가 있었다.

그래서 급한대로? 내 개인 서버에 임시로 서버를 배포하였다.

 

처음엔 서브도메인 없이 everdu.com/api/pumasi/ 이런 형식으로 배포하였었는데, 이렇게 배포하니까 장고에서 url 인식을 /api/pumasi/ 를 포함하여 하는 문제가 발생했다.

즉, 원래 로컬 테스트에서 /care 만 하면 되는데, 이렇게 배포하면 /api/pumasi/care 로 들어가야 되는 것이다.

 

이 문제를 해결하려면 HOST_ADDRESS 상수값으로 /api/pumasi 를 포함해서 넣고, 모든 API 호출은 HOST_ADDRESS + 'api url' 주소로 하도록 하면 되겠으나, 이 경우 프론트도 요청 주소 경로를 이렇게 코딩해야 하고, 로컬 호스트 테스트할 때와 배포할 때 주소가 달라져서 개발 후 테스트 할 때 도 불편한 점이 많았다.

 

그래서 서브 도메인으로 pumasi 를 넣어, pumasi.everdu.com 도메인으로 배포하였고, 서브도메인 설정을 위한 NGINX 설정값을 구글링하여 가볍게 공부한뒤 추가하였다.

 

리드미 작성

파이어베이스 설정이 들어가면서 개발환경 세팅이 복잡해지기 시작했다.

그래서 어떤 과정으로 개발환경을 세팅해야 하는지 아랠와 같이 리드미를 자세히 작성하였다.