---
# System prepended metadata

title: Untitled

---

### 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 |
        | -------- | -------- |
        | name, description  | statuscode, _id, name, description |
        
        
- DELETE
    - `DELETE /accountbook/:accountbookid`

        | request | response |
        | -------- | -------- |
        |  | 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, type, 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 |
        | -------- | -------- |
        | content(내용), type(수입/지출), category({name, type, icon}), cost, date, payment({name, descriptioni})| statuscode |
     
     - mongoose에서 update를 할 때 return 값이 전체 data가 나오지 않기 때문에 응답코드만 주는 것이 편할 것 같다.

- DELETE
    - `DELETE /accountbook/:accountbookid/transaction/:transactionid`

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

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

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

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


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

        | request | response |
        | -------- | -------- |
        | name, color, desc | statuscode  |

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

### 카테고리

- CREATE
    - `GET /accountbook/:accountbookid/category`
    
        | request | response |
        | -------- | -------- |
        | name, type(수입/지출), icon | statuscode, _id, name, type, icon |
        
- UPDATE
    - `PATCH /accoutbook/:acccountbookid/category/:categoryid`

        | request | response |
        | -------- | -------- |
        | name, type, icon | statuscode |
        
- DELETE
    - `DELETE /accoutbook/:acccountbookid/category/:categoryid`

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