[카카오 테크 캠퍼스 1기] 3단계 Garden (API 문서 작성)

카카오 테크 캠퍼스 (이하 카테캠) 의 3단계로 FE + BE 협업 프로젝트를 진행하였다. 

 

아이디어 도출 -> 기획 -> 개발 -> 배포 까지 모두 팀에서 이루어졌고, 오늘 부터 진행하면서 맞닥뜨린 문제점, 해결방안, 느낌점 등에 대해 회고 블로그를 작성할거다 ! 

 

회고에 앞서, API문서와 프로젝트 룰을 설명하면서.. 어떻게 프로젝트 시작 전 기반을 다졌는지 기록하려한다. 

이번 글에선 전체적인 API를 보고 변동이 있었던 API를 간단히 설명하겠다. 

 

1. 아이디어 도출 및 기획 

[카카오 테크 캠퍼스 1기] 아이디어톤

관련해서는 아이디어톤 게시물에 작성해두었다. 

 

2. API 문서

 

(배포 스웨거가 닫혀서 표로 대체) 최종 배포 기준의 api 문서 

 

API : Application Programming Interface

두 소프트웨어 구성요소(어플리케이션)의 통신을 도와주는 메커니즘. (백앤드와 프론트앤드의 통신)

인터페이스는 이 두 소프트웨어 간의 서비스 계약. (요청 -> 응답)

이때 프론트에서 어떻게 요청하고 백앤드에선 어떻게 응답할지 에대해 정리 해놓은 것이 API 문서이다! (프로젝트 Garden에서는 백앤드와  RESTful API 를 사용하여 통신하였다. ) 

 

RESTful API란 무엇인가요? - RESTful API 설명 - AWS

 

우리 프로젝트에서 제공 되는 서비스는 다음과 같다. 

1. 영상 서비스

2. 멘토 / 멘티 매칭 서비스

3. 채팅 서비스 

 

먼저 채팅 관련해서는 웹 소캣으로 직접 개발하는것은 현실적으로 어려울 것이라고 판단되었다. 아무래도 프로젝트 자체가 제공되는 서비스가 많은 편이라 기한내에 구현 할 수 없을 것 같다 생각했고, 채팅 서비스만 외부 API를 사용하기로 했다. 

 

기존의 기획을 세부화 하면서 그리고 개발을 진행하면서 삭제되거나 추가된 기능들이 있었고 이에 맞춰 api도 변동됐었다. 

 

변동 API 

 

 (1) emailcheck 

처음 api 작성 당시에는 생각을 못했는데, 중복 이메일 체크는 기본적으로 회원가입 시 필요한 기능이라 추가했다. 

 

 (2) passwordcheck 

거의 마지막에 추가된 기능이다. 개인 정보 수정 시 프론트 단에서 리턴해준 비밀번호 == 입력 비밀번호 체크 하려 했던게.. 사실 생각해 보면 말도 안된다.. 그냥 요청 응답으로 비밀번호를 담아주려 했다니😲!! 아무튼 그래서 서버 토큰을 담아 입력 패스워드 == 사용자 패스워드 검증하여 개인 정보 수정을 가능케 하였다. 

 

 (3) video/interest

이 부분도 기획 당시에는 고려하지 못했었다. main 에서 한번에 요청을 보내려고 했었는데 그게 가능할리가 ㅎㅎ

로그인/ 로그아웃 여부에 따라 보여지는 메인 페이지가 다르다. 

 

 

로직은 아래와 같다. 

- 로그인 한 사용자의 경우 (인증된 사용자) : 1번과 2번 모두 보임 
1번은 카테고리(관심사)를 선택하여 해당하는 비디오 정보를 불러온다. 
( videos/main 에 파라미터로 카테고리와 페이지값을 url에 담아 get 요청 -> 백앤드에서 해당 카테고리의 해당 페이지 정보만을 리턴 )

2번은 사용자가 회원가입 시 선택했던 카테고리에 해당하는 4개의 비디오 정보를 불러온다. 
(videos/interest 에 토큰을 헤더에 담아 get 요청 -> 백앤드에서 해당 사용자 정보에서 카테고리를 확인 -> 카테고리에 해당하는 영상 정보 4개 리턴) 
- 로그인 안한 사용자의 경우 (인증되지 않은 사용자) : 1번만 보임
(로직은 위에 설명한 것과 동일)

 

 (4) profiles/simple

사용자 식별 정보 get 요청 api 인데, 이 부분은 다른 게시물에서 자세히 다루겠다. (왜냐? 되게 많이 고민했거든....)

 

 (5) 프로필/ 개인정보 

1. 처음에 api 가 완성되고 서버를 연결 했을 땐, profile에 접근하려면 토큰이 필요했었다. 그러니까 해당 사용자만 접근이 가능했던건데 기획의도는 멘토/멘티 신청 시 상대방의 프로필을 열람하여 확인하는 용도였기 때문에 profile/:id 파라미터 값으로 누구나 프로필을 조회할 수 있게 수정하였다. 

2. 프로필 수정/ 개인정보 수정 이렇게 두 페이지가 나뉘어져있었는데 지나치게 중복된 기능이라고 생각했다. (개인정보 수정에서 프로필 정보에 해당하는 부분 모두 수정이 가능하기에) 

그래서 개인정보 수정 페이지에서 모든 처리가 이루어지도록 통일했다. 

 

 (6)  users/interest 

이건 삭제된 api인데, 이 부분도 다른 게시물에서 길게 이야기해야겠다. 

 

 

 

이렇게 보니 다 다른 게시물에서 다루는것 같은데 아무튼 정리 해본 내용이고, 

생각 보다 개발하면서 api 문서에 많이 의지하게 되어 처음부터 기반을 잘 잡는것이 중요하다고 느꼈다. 

 

우리 팀 같은 경우에 프론트 쪽에서 api 문서를 작성했는데, 그러다 보니까 백앤드 분들과 다르게 생각하고 있던 부분들이 좀 있었다. (예를 들어 응답 객체 형식이라던가...) 

 

또 아무래도 프로젝트 기획기간이 짧았던 만큼 디테일 하게 생각하지 못했기도 하고, 그때 당시 나는 통신에 대한 이해도가 많이 떨어져있었어서 그런지 API 변동이 잦았다.  

API문서 변동 이슈에 따른 코드 변화 이슈들도.. 항상 같이 발생하기에 이를 논의하는 과정이 꽤나 걸렸다.