논의사항
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 중복 확인 프론트에서 하자
API .. 게시글 상세 조회
- title: 삭제조치 필요
- categoryID: 별도의 category id를 request하여 category name을 response 받는 api가 없기 떄문에 categoryName 속성을 추가로 주시면 좋겠습니다 → 카테고리 전체 조회에 있는 "name"이 category name인데, 혹시 카테고리 전체 조회 하기전에 필요하다면 어디에 필요할까요? 어느 API에 추가할지 참고해볼게요! +post detail 페이지에 categoryName이 들어가는 부분이 없는 것 같아요
- like (Boolean): 속성 필요 → boolean 속성말고 따로 테이블을 두고 사용하려구요! 게시글마다 boolean으로 설정하면 user마다 좋아요를 했는지가 구분이 안되거든요!
- favorite Boolean): 속성 필요 → 넵 확인했습니다!
- imageURL: 포스트별 이미지 저장할 속성 추가 필요