-
71 TIL ( API )내일배움캠프 2023. 2. 7. 22:12
오늘 한 일 : api 설계 디테일 업
주요 공지 : 이번주 금요일 오전 11:30 튜터님 기술면담 있음. 회의 통해 기술면담 설문지 작성 필요함.
내일 할 일 : [오전 9시반 회의] / api 설계 무조건 완성 / 우리팀 그라운드룰 결정 / 기능별 마감기한 결정
오늘의 반성 : 팀원 모두 수동형인 편이라 비슷한 가치의 A&B 중 결정해야하는 상황에서 결정이 쉽지 않아토론 시간 지연. 내일부터 이런 선택지가 발생하는 경우, 주사위 굴려서 걸린 사람이 무조건 결정 하기로 함.
오전 9:30 ~ 1차 회의
오늘 해야할 일- API 명세 완성하기
- 기능 좀 다듬고, 우리 서비스의 mvp가 뭔지 결정하기
- 엔티티 설계하고, ERD 간단하게 잡기 (코드퍼스트 식으로)
- 어제 작성한 API, 프로젝트에 대한 의견 수렴 및 검토
조운 : 기능이 많지 않나..? 하는 생각을 약간 했습니다. 다른조들 경우 '예약' '커뮤니티' '중고거래'특정 파트를 파고있다 생각함
예진선 : 물건대여를 넣는게 좋지 않을까? WHY 다른 프로젝트와 차별화를 위해.. BUT 이미 기능이 많은거 같고, 기능적 측면에선 특별한건 아닌거같음.
이상환 : 기능이 다 비슷해서, 하나로 합쳐서 포괄적으로 사용하는건 어떨까? 공간대여가 핵심이지 않을까.
김민재 : 중요한 CRUD 로 생각되는걸 먼저작업하고, 이후 어떤걸 빼고 만들지는 추후 정하는게 어떨까?
최찬호 : 다른조들꺼 봤는데, 많거나 딥하지 않음. 우리정도가 적당한게 아닐까 우리는 공간대여 + 커뮤니티가 둘다 mvp다
우리의 MVP 서비스가 뭘까 !?
3:00 특강 이후 2차 회의
- API 문서 완성
- 기술멘토링 문서 관련 얘기
- 코드 컨벤션 & 깃플로우 전략 & 우리팀 룰 정하기
- 1차 마감 날짜 정하기
- 기능(할일목록) 분류 & 역할 맡기
- Repo 생성 후, 엔티티 설계 (+ 서비스 메소드 인터페이스 만들까유?)
- 좋아요 구현 어떻게 하는게 좋을까?
1. 객체 생성?
2. 게시글이 좋아요한 유저 list로 갖고있기 - 담당자가 알아서 하기로 - http 상태코드 201 (created) : 객체 생성할때
- 유저 & 샐러 테이블을 어떻게 해야하는가
[기본유저 테이블] -가명
ID 1,2,3,4,5...
이메일ID (아이디대신임. 이메일을 바꿔도, 아이디값으로서의 이메일값은 그대로임)
닉네임
이메일 (연락처로서의 이메일임)
비밀번호
상태메세지
프로필이미지
7:30 식사 이후 3차 회의
[판매자 프로필 테이블] -가명 (객체로서는 유저를 갖고있음)
(ID) 1,2,3,4,5....
userID 3,6,8,10....
업체명
대표자명
대표번호 (지역번호 + 핸드폰 둘다가능) ** - 없이, 숫자만 DB에 저장 ex) 01012341234
지역명
- 의문점
업체명, 사업소명(만정낚시터) << 따로 하는게 맞을듯함. 한사업자명으로 여러사업소있을수있다.
- 수락&거부 갈라말아??? 일단 [1]로결론, 단 이거 담당자가 해보다 아니면 [2]로 바꿔도 됨!
[1] api 합침 3.
1. 컨트롤러가 requestdto 수락/거부 이걸 받음.
2. "수락/거부" > 서비스로 보내줘.
3. 서비스 : 수락일 경우 > 신청서객체의 작성자를 찾아서 등급을 판매자(작성자객체의 메소드)로 바꿔주고, 신청서 객체의 처리상태를 "수락"(신청서객체가 가지고있는 메소드에게)으로 바꾼다.
거부일 경우 > 신청서객체의 처리상태를 거부로 바꾼다
그외의값 > 유효한값을 보내란말야 라고 예외처리
4. 컨트롤러 : "수락처리완료"||"거부처리완료"를 msg로 해서 프론트한테 보낸다.
5. 프론트는 (json)을 받는다.... 그다음에 어케되는지 난모름...
[2] api 분리 + 서비스까지 다 갈라짐
api/admin/authourities/1/accept > 수락처리면 여기로
api/admin/authourities/1/reject > 거부처리면 여기로