[TIL] API Document 피드백 수렴 및 기술, 컨벤션 회의

오늘 한 일

• API Document , Table Document 피드백 수렴
• 기술 스택 선정
• Git Commit, Branch Convention 설정
• 1차 회의록 작성

작업 내용

블로그 포스팅을 통해 Restful API에 대해 별도로 기록하였다.

API Document 수정 과정

API 문서를 하루동안 정신없이 작업하다보니 실수도 많았고 수정해야 할 부분이 중간중간 많이 보였다.
크게 수정 내용을 구분해보면 다음과 같았다.

1. Role 분배
2. 자원 표현 수정
3. Method 수정

첫 번째로 Role의 분배는 참으로 모호했다. Manager라는 역할을 어떤 역할로 가정하고, 어떤 상황까지 가정해서 부여해야 할지 고민끝에 매장에 대한 등록, 삭제는 불가능하지만 영업 시간, 메뉴 등록,추가,수정,삭제등 가게의 전반적인 운영을 할 수 있는 자격으로 설정했다.
또한 결제에 대해서 매장의 오너와 매니저가 어디까지 관여 가능한가에 대해서 계속적인 토론을 하고 튜터님에게 여쭤봤다. 결제 요청과 결제 취소는 고객 또는 전체 관리자가 가능하지만 결제 수정시에는 어떻게 해야하나 많은 고민과 튜터님의 조언끝에 MASTER가 접근 가능하도록 설정했다.
그 이유는 아래 사진과 같다. 빨간 네모 박스를 보면 유저가 결제를 누름과 동시에 수행되는게 아닌 중간단계에서 검증이 한 번 더 이뤄진다. 이때 내부 데이터에 변조가 일어났는지 한 번 더 체크하는 것이다. 만약 500원을 결제했는데 5000원이 결제된다면 이는 중간의 데이터에서 변조가 일어난 것이기에 유효한 요청이 아니라는 검증이 필요한것이다.

https://docs.tosspayments.com/guides/v2/payment-widget/integration

두 번째 자원 표현은 나에게 가장 어려웠던 부분이었다. 평소에는 무지성으로 주소를 만들었는데 실제 현업에서는 이 부분의 표현에 대해 가장 중요하게 생각하고 계셨던것 같다. 왜냐하면 현재는 모놀리딕이지만 이를 마이크로서비스로 분리하게된다면 이 주소 또한 각 도메인별로 분리되기에 주소가 변경되는 문제가 발생되지 않도록 주의해야 할 필요가 있기 때문이었다.
평소에는 항상 api/v1/user와 같이 api/v1/뒤에 어떠한 자원을 추가했었는데 이번에는 새로운 방식으로 작성하게 되었다.
첫 번째로 POST /api/admin/v1/sign-in 이와 같이 admin이 앞쪽으로 들어가고 마지막에 인증에 대한 행위를 기록하는 API가 있었으며, PUT /api/menus/v1/{restaurantsId}/restaraunt/{menuId} 이 주소처럼 멱등성을 고려하고 주체가 주소의 어디에 표현되는게 좋은지 고려를 해볼 필요가 있었다.
또한 전체 조회라는 기능은 최대한 기피해야 하는 API였다. 만약 수백개의 데이터라면 전체를 한 번에 불러오는게 가능했지만 그게 1억, 10억개 이상이 된다면 서버에 부하가 갈만큼 큰 데이터를 불러오는 작업이기에 서버에 치명적인 문제가 발생할 수도 있기 때문이다. 페이징을 습관화하고 데이터 조회시 어떤 쿼리와 어떤 사이즈의 데이터가 올지 항상 고려해야 했다.

세 번쨰는 Method 수정이였다.
멱등성이라는 개념을 고려해보지 않고 넣었던 API들에 대해서 같은 요청을 여러 번 날려도 데이터는 동일한가?에 대한 초점을 두고 다시 수정하게 되었다.
만약 PATCH라는 메서드를 사용해야 한다면 어떤 자원을 변화시켜야 할 지 표기가 필요하다는 걸 다시 인지하게 되었다.

회의록 작성

팀장으로서 물어보고 수정한 내역들을 하나씩 정리하는 과정이 필요했다. 오늘은 정신없이 물어보고 수정하느라 그 내용을 모두 제대로 기록하지 못했지만 일부 메모라도 건져서 다시 기록해두려고 한다.
회의록또한 포트폴리오에 제출할 수 있는 하나의 문서라 생각하고 꾸준히 만들고자 한다.

기술 스택 및 컨벤션 설정

기술은 가장 최소한의 필요한 기능들로 구성하게 되었다. 우리의 1차 목표는 기본 요구사항에 대한 충족이고, 그 부분을 만족한 뒤에 2차 목표로 더 넣어보고 싶은 기술을 추가하기로 했다.
이 과정에서 필요한 커밋, 브랜치 전략들을 구성하게 되었고 이 내용은 깃허브 리드미에 기록해두었다.

내일 할 일

• 프로젝트 생성
• 도메인별 역할 나누기
• 회의록 작성