논의사항

API 전체 관련 질문(to Backend)

• userID: data type을 number-> string으로 두는게 적절할거 같습니다

  • *ID: data type이 number→string으로 두는게 적절할 거 같습니다. number를 accumulate 방식으로 주게 되면 나중에 table 사용하다 서버가 죽어서 accu 값이 0이 되면 primary key가 중복이 될 가능성도 있지 않을까요?

  → PK 값은 DB에서 중복되지 않게 들어가요! 서버가 죽으면 안들어가겠죠. 중복될 가능성은 없을 것 같습니다!

• API data 속성을 없애고, body에 통으로 넣게 된 경위가 궁금합니다 → 굳이 data 안에 넣어주는게 불필요하다고 생각했습니다. 덧붙이자면 응답 바디의 내용에 접근할 때 data.exampleId로 접근한다고 들었습니다. 전에 저희가 설계했던대로 응답 바디 안에 "data":{~}와 같은 형식으로 넣어주게 된다면 프론트에서 data.data.exampleId 이런 식으로 값을 꺼내야한다고 하더라구요!

• web socket 관련하여 backend 진행 현황이 어떻게 되고 있나요? → 웹 소켓은 아직 진행못했습니다. 다음주에 좀더 우선순위인 것들 끝나고 바로 해볼게요!

• OAuth 관련 진행 현황 공유 부탁드립니다 → OAuth보다 웹소켓이 우선인 것 같아서 웹 소켓 구현 이후에 진행할게요!

• 오늘 API 어디까지 완성할 수 있으실까요?

API 요청사항(2순위 .. 전체 API 완성후 진행 부탁드립니다)

• request:{categoryId} → response: {categoryName}
• request:{categoryName} → response: {categoryId}

둘러보기 페이지 - 게시글 조회

• user 속성에 객체형태로 user 정보 받는 게 좋을 것 같습니다! userId만 받아서 하나하나 돌리면 리소스가 많이 들 것 같아서요!

API 변동사항(1순위 .. 빠른시일내로 처리 부탁드립니다)

• 게시글 조회관련 모든 API에 createdAt 추가 요청 (시간 정보 포함되어야 함)

게시글 등록

• title: 삭제조치 필요
• 카테고리 name 중복 확인 프론트에서 하자