[5~9일차] 2번째 기업과제

🎃 과제 story

두번째 기업과제는 페이히어의 과제였다.

간단한 가계부를 만드는 과제에서 모델링과 가계부 API 설계를 담당했다.

가계부 API 설계는 팀원과 공동으로 작업을 했는데 서로의 작업 현황을 파악하고 원활한 코드 리뷰와 의견 공유를 위해 설계할 URL과 메서드를 나열해놓고 하나씩 작업한 후 내용을 공유해서 레포지토리에 push하는 식으로 진행했다. 

작은 단위의 서비스를 만드는 과정이었지만 RESTful하게 그리고 확장성을 고려하니 생각보다 고민해야할 부분이 많았다. 

 

🌄 확장성

• 단순하게 수입, 지출내역의 log만 저장하는게 아닌 사업장별 가계부를 만들고 관계 테이블로 log연결해서 사업장별 가계부 관리가 가능하게 만들었다. 
• 가계부별 로그를 확인할 때 시리얼라이저에서 시작 시점부터 현재 로그까지 잔액을 계산하는 로직을 만들었다. 
  • 날짜별 잔액을 계산하는 로직은 구현했는데 한 객체별로 잔액을 계산하는 부분은 구현하지 못했다.

                                                                  

💨 RESTful

기본적인 CRRUD를 구현했는데 Delete의 경우 soft delete를 구현해야했다. 

 

my idea

• /record : C  POST / 기록 생성
• /record : R(list) GET / 기록 리스트 조회
• /record/<obj_id> : R GET / 기록 단일 조회
• /record/<obj_id> : U PUT / 기록 수정
• /record/<obj_id> : D DELETE / 기록 삭제(소프트)
• /record/<obj_id>/recovery : PATCH / 기록 복구

서비스에 데이터를 완전 삭제할 기능을 구현할 예정은 없어서 개인적인 생각으로는 url 2개에 각 행위별로 메서드를 나누거나 복구기능만 따로 빼는 경우를 생각했다. 

 

team idea

• /record : C  POST / 기록 생성
• /record : R(list) GET / 기록 리스트 조회
• /record/<obj_id> : R GET / 기록 단일 조회
• /record/<obj_id> : U PUT / 기록 수정
• /record/<obj_id> : D PUT / 기록 삭제(소프트)
• /record/<obj_id> : PUT / 기록 복구

수정 후 

• /record : C  POST / 기록 생성
• /record : R(list) GET / 기록 리스트 조회
• /record/<obj_id> : R GET / 기록 단일 조회
• /record/<obj_id> : U PUT / 기록 수정
• /record/<obj_id> : D PATCH/ 기록 삭제(소프트)
• /record/<obj_id>/recovery : PATCH / 기록 복구

팀원들과 회의를 통해서 최종적으로 만들어진 api 구조이다.

일단 소프트 삭제인데 Delete 메서드를 사용하는건 영구 삭제의 느낌이 강하다고 해서 Put 메서드에 수정, 삭제, 복구 기능을 넣었다가 Patch 메서드를 사용하는 방안으로 수정했다. 

 

🎡 회고

2번 진행된 과제에서 모두 api 설계를 담당을 하게 되었는데 api를 RESTful하게 설계하는건 어느정도 공부가 되었지만 배포와 서비스에 대해서는 공부가 부족하다. 

다음 프로젝트에서는 배포나 테스트 작성을 담당해서 부족한 부분을 채워야겠다.