API 설계 협의

API - 대결 공고 작성자는 대결 신청자와 대화하기 위해 신청을 수락 또는 거절할 수 있다.

• 해당 API 는 매칭 요청의 수락 여부 상태만 변경합니다.

• 소통 창구와 별개로 가져갑니다.

API 설계 피드백

• 개발을 하면서 의문사항이 들 때 마다 바로바로 질문하는걸로 하겠습니다.

📄 API 설계 피드백

새로운 유저 스토리 추가 필요

✉️ 프론트 공유 내용

• 아래 3가지 스토리 추가가 필요할 것 같습니다
• 초대목록 조회
• 채팅목록 조회
• 채팅기록 조회

• 어떻게 생각하시는지 댓글 부탁드립니다

🐶 백엔드 의견

• 좋습니다! ⇒ 스토리에 추가하기

대결 신청에서 요청 내용이 필요할지

✉️ 프론트 공유 내용

• 사용자는 대결에 대한 의지 표현하기 위해 신청을 한다. 라는 스토리에서 요청 내용이 NOT NULL로 되어있어서 질문드립니다
• 저희는 신청 시에 신청에 대한 내용이 필요없다고 생각했습니다
• 한다면 should나 could로 고려해보는 건 어떤가요?

🐶 백엔드 의견

• 빼도 상관없을 것 같구요, 필요없다면 컬럼 자체를 제거 하는걸로 가는게 좋을것 같습니다.

• ⇒ 요청 내용 넣는 걸로 확정!

채팅 목록 조회

✉️ 프론트 공유 내용

• ERD 상에서 매칭 요청 목록을 불러오는게 프론트 입장에서는 채팅방 목록을 불러오는 것이기 때문에 엔드포인트를 api/chats 으로 할 지 api/proposals 이나 또 다른 의견 있다면 부탁드립니다

🐶 백엔드 의견

• /api/chats 이 좋은 것 같습니다. ⇒ 확정!

팀 초대 엔드포인트

✉️ 프론트 공유 내용

• api/teams/invitation 로 되어있는데 api/teamInvitations or api/invitations 로 되는 건 어떤가요?

🐶 백엔드 의견

• /api/teams/{id}/invitation은 어떨까요?

• ⇒ 계층형 구조로 결정

팀 초대 수락 거절

✉️ 프론트 공유 내용

• 분리가 필요하지 않을까 생각했습니다

• 수락은 멤버 생성이고 거절은 초대 상태만 바뀐다고 생각해서 혹시 이에 대한 의견도 부탁드립니다

🐶 백엔드 의견

• 좋습니다! 수락은 생성이고, 거절은 수정이니까 분리되는게 맞겠네요! 👍

• 유저스토리도 분리하는건 어떨까요? 🤔

• ⇒ 분리로 결정