# 서비스 흐름, API

### 1. 진입
#### 첫 화면은 가계부 목록
- 로그인 여부 판단
- 되어있으면 가계부 목록
- 안되어 있으면 로그인 페이지
<br>
### 2. 가계부 목록
- READ
- `GET /accountbook`

| request | response |
| -------- | -------- |
| | statuscode, [{_id, name, description}...] |

- 이 때 accountbook 안에 transaction들도 모두 가지고 올 것인가?
- 만약 트랜잭션이 엄청 많다면 모든 transaction들을 가지고 있는 것이 성능 문제가 있을 것 같다.
- {_id, name, description}만 가져오고 accountbook 목록은 useState로 관리한다.
- accoutbook 전체를 가지고 있는 store를 만들것인가?
- 굳이 필요가 없을 것 같다.
- 우리의 UI 상에서는 가계부 선택으로 돌아가서 가계부를 선택했을 때 상태가 유지될 필요가 없을 것 같다.
- CREATE
- `POST /accountbook`

| request | response |
| -------- | -------- |
| name, description | statuscode, _id, name, description |

- UPDATE
- `Patch /accountbook/:accountbookId`

| request | response |
| -------- | -------- |
| _id, name, description | statuscode, _id, name, description |

- DELETE
- `DELETE /accountbook/:accountbookId`

| request | response |
| -------- | -------- |
| _id | statuscode |

### 3. 가계부 내역
- READ
- `GET /accountbook/:accountbookId`
| request | response |
| -------- | -------- |
| | statuscode, {_id, name, description, category, user, payment, transaction} |

- 특정 어카운트북의 정보를 전부 store 데이터에 넣어서 전역으로 관리한다. 즉 어카운트북 안의 모든 페이지가 이 스토어를 참조한다.
- 여기서 달력과 차트는 store에 있는 값을 직접 변경하지 않고
참조만 하기 때문에 특별히 API가 필요하지 않다.
- CREATE
- `POST /accountbook/:accountbookId/transaction`
| request | response |
| -------- | -------- |
| content(내용), type(수입/지출), category({name, icon}), cost, date, payment({name, descriptioni})| statuscode, {_id, name, description, category, user, payment, transaction} |

1. db.accountBookModel.find({_id})
2. accountBook.transactions
3. REQ => transaction 만들
4. accountBookModel.update({_id}, {transactions : [ ...accountBook.transactions , transaction ]})

- UPDATE
- `PATCH /accountbook/:accountbookId/transaction/:transactionId`

| request | response |
| -------- | -------- |
| _id, content(내용), type(수입/지출), category({name, icon}), cost, date, payment({name, descriptioni})| statuscode |

- mongoose에서 update를 할 때 return 값이 전체 data가 나오지 않기 때문에 응답코드만 주는 것이 편할 것 같다.

- DELETE
- `DELETE /accountbook/:accountbookId/transaction/:transactionId`

| request | response |
| -------- | -------- |
| _id | statuscode |

### 4. 결제 수단 관리
- READ
- accountbook 전체를 가져올 때 embeded 돼서 나오기 때문에 가계부의 결제수단만 가져오는 api는 필요가 없다.

- CREATE
- `POST /accountbook/:accountbookId/payment`

| request | response |
| -------- | -------- |
| _id, description | statuscode, _id, name, description, color |

- UPDATE
- `UPDATE /accountbook/:accountbookid/payment/:paymentid`

| request | response |
| -------- | -------- |
| _id, description | statuscode |

- DELETE
- `DELETE /accountbook/:accountbookid/payment/:paymentid`

### 카테고리

- CREATE
- `GET /accountbook/:accountbookId/category`

| request | response |
| -------- | -------- |
| name, icon | statuscode, _id, name, icon |

- UPDATE
- `PATCH /accoutbook/:acccountbookId/category/:categoryId`

| request | response |
| -------- | -------- |
| name, icon | statuscode |

- DELETE
- `DELETE /accoutbook/:acccountbookId/category/:categoryId`

| request | response |
| -------- | -------- |
| name, icon | statuscode |

### 설정
1. GMT
2. 요일 고르기
3. 카테고리 설정
4. 다크모드
5.

# 기타 논의사항

1. FE, BE에서 동시에 사용할 수 있는 type 폴더를 두면 어떨까?

2. 추가 구현 사항으로 버킷 리스트 페이지를 만들어서 선택적으로 작성할 수 있게 제공해준다.

## url을 가계부 별로 다르게 할 것인가?

### 1. url을 가계부 별로 다르게 하지 않는다.

이 방법을 쓰면 상세 url로 접근을 했을 때 store에 있는 가계부 데이터를 가지고 렌더링을 한다.

#### 장점
권한이 없는 가계부에 들어갈 수 있는 가능성을 없앨 수 있다.

#### 단점
url로 공유를 하거나 뒤로가기로 이전에 봤던 가계부로 돌아갈 수 없다.

### 2. url을 가계부 별로 다르게 한다.

`/accountbook/:accountbookId/calander` 같은 url로 접근 했을 때 :acccountbookId에 해당하는 가계부 데이터를 가지고 렌더링을 한다.

#### 장점
url로 공유를 하거나 뒤로가기로 이전에 봤던 가계부로 돌아갈 수 없다.

#### 단점
링크로 직접 들어갔을 때 권한을 확인하는 부가적인 작업이 필요하다.