원티드 - 프리온보딩
디셈버앤컴퍼니 기업과제
[2] 주요 기능 & API 설계
1. API 설계
상세보기
2. 고려항목
1. 고객관리 - 로그인
요구사항에는 포함되어있지 않지만 투자 조회(또는 투자금 입금) 시 고객이 본인의 투자를 조회(또는 투자금 입금)한다고 가정하고 JWT를 통한 로그인 기능을 구현하고 고객인증을 통해 본인의 투자(계좌)만을 조회(또는 투자금 입금)할 수 있도록 계획
- 고객 데이터 생성시 비밀번호는 기본 고정값으로 설정, 비밀번호 기본 고정값은 .env파일에서 관리
2. 고객 - 투자(계좌) 관계
제공된 데이터셋에는 1명의 고객에 1개의 투자(계좌)로만 구성되었지만 구조적으로 1개 이상의 투자(계좌)를 가질 수 있다고 가정하고 FK로 계획, 따라서 투자 조회시 본인이 가진 투자(계좌)를 리스트로 조회할 수 있다.
- 투자 조회 정리
(고객 로그인)
-> 고객 본인의 투자(계좌) 리스트 조회
-> 그중에 하나 선택 시 해당 투자(계좌)에 대한 상세 조회
-> 보유 종목 선택시 해당 투자(계좌)의 종목 리스트 조회3. '투자 조회', '보유 종목 조회' -> 응답 데이터에 id 포함
'투자 상세 조회'를 제외한 '투자 조회'와 '보유 종목 조회' 기능은 여러개가 리스트로 조회될 수 있으므로 Front에서 각각의 개체를 식별할 수 있는 고유 id값을 응답 데이터에 포함시킬 계획
기타 추가사항
1. Batch
제공되는 데이터셋을 매일 최신 데이터로 갱신할 수 있어야함 오류 데이터 구분해야 함
2. 적절한 오류/예외 처리
3. 원본 데이터와 응답 값에 일관성(Consistency) 이 유지
투자금 입금 기능에서 고객의 총 자산을 업데이트할 때 일관성이 유지되도록 구현해야함
3. 주요 기능
고객 관리
- 로그인 : JWT 토근 인증
투자관리
1) 데이터 조회
- 투자 화면
- 계좌명
- 증권사
- 계좌번호
- 계좌 총 자산
- 투자 상세 화면
- 계좌명
- 증권사
- 계좌번호
- 계좌 총 자산
- 투자 원금
- 총 수익금 (총 자산 - 투자 원금)
- 수익률 (총 수익금 / 투자 원금 * 100)
- 보유 종목 화면
- 보유 종목명
- 보유 종목의 자산군
- 보유 종목의 평가 금액 (종목 보유 수량 * 종목 현재가)
- 보유 종목 ISIN
2) 투자금 입금
- Phase 1
입금 거래 정보들을 서버에 등록합니다.
- 요청 데이터
- 계좌번호
- 고객명
- 거래 금액
- 응답 데이터
- 거래정보 식별자 : 요청 데이터 묶음을 식별할 수 있는 key 값
요청 데이터 { "account_number": "123123", "user_name": "아이작", "transfer_amount": 1000 } 응답 데이터 { "transfer_identifier": 111 }```
Phase 2
phase1 에서 등록한 거래정보 검증 후 실제 고객의 자산을 업데이트합니다.
거래 정보를 hashing 하여 서버에 phase2 요청을 하면 서버에서는 phase1 에서 등록하여 저장된 데이터를 hashing 하여 동일한 데이터에 대한 요청인지 검증을 합니다. 검증에 성공하면 고객의 총 자산을 업데이트하고 성공 응답을 하고, 검증 실패 시 자산 업데이트 없이 실패 응답을 합니다.
- 요청 데이터
- phase1 요청 데이터 계좌번호, 고객명, 거래 금액 순서로 연결한 string 을 hash한 string.
- phase1 에서 응답받은 거래정보 식별자
- 응답 데이터
- 입금 거래 결과
요청 데이터 { "signature": "82b64b05dfe897e1c2bce88a62467c084d79365af1", // "123123아이작1000" 을 sha512 hash 한 값. "transfer_identifier": 111 } 응답 데이터 { "status": true }
📄 기획문서
노션 - 디셈버앤컴퍼니 기업과제
kimphysicsman