프로젝트 관련 질문 답변 SA질문

1. API 설명 중 - "특정회원에대해 신고하는 경우 /api/v1/users/{userId}/report라고 작성해주는것보다 회원신고라는 Entity가 새로 생성된다는점에서 /api/v1/report/{userId} 이런식으로 url을 변경하였는데 url을 이렇게 바꾸는게 맞는건지 잘 모르겠습니다. / 또한 특정 상품에대한 좋아요같은경우 /api/v1/product/{productId}/likes 이런식으로 뒤에 likes를 붙였는데 위에서 한것과같이 /api/v1/likes/{productId} 라고 생각하니 엄청 어색하다고느껴져서 어떤식이 좀 더 맞는건지 궁금합니다." 이 내용도 위와 동일하게 어떻게 결론 내셨는지 진행상황을 설명 해주세요.

: 계층구조에 집중하기보다는 특정 리소스에 대한 동작에 집중하여 가독성을 높이는 쪽으로 url을 디자인했습니다. 신고라는 Report Entity가 리소스이면서, Restful API를 나타내기 위해서 /api/v1/reports를 기본으로 정했고, Controller RequestMapping주소를 활용하면서 생성 시 /api/v1/reports + RequestBody형태로 수정, 삭제 시 /api/v1/reports/{reportId}형태로 결정했습니다. 또한 계층형으로/api/v1/reviews/{reivewsId}/comments 쓰게 되면 리뷰에만 사용해야되어 비슷한 구조의 메서드들이 많이 생길수 있고 딱 리뷰에만 사용해야 하게때문에 새로운 계층이나 관계를 추가하기 어렵습니다. 하지만 비계층형 /api/v1/comments 으로 하면 다른곳에서도 쓸수있기 때문에 ****유연성이 높아서 데이터 구조에 새로운 항목이나 관계를 쉽게 추가할 수 있습니다.

1. API Context Path 설계 중 중간에 /v1을 다 삽입 하셨는데 나중에 어떤 활용을 염두해 두셨을까요? 간략하게 시나리오 예제를 만들어봐 주세요.

: v1을 삽입한 이유는 API버전을 url에 포함시키는 것이 후에 버전 업데이트에 대비해서 클라이언트와 서버간의 호환성 유지에 적합하다고 판단했고, 버전을 명시적으로 표시하는 것이, 서버 배포 후에 API가 업데이트될 시 이전 버전과 새로운 버전간의 관계를 효과적으로 나타낼 수 있다고 생각했습니다.

• 시나리오 예제
  • 버전 1.0 출시 : "/api/v1/image”를 사용한 기본적인 기능 제공
  • 기존 기능에대한 피드백 및 업데이트 : 이미지파일 생성기능에 이미지파일 리사이징 기능을 도입
  • 버전 2.0 출시 : v1에서 제공하는 기능에 추가적인 기능을 추가하여 "/api/v2/image"로 업데이트

1. ERD 중에 - "현재 저희의 설계단계에서는 식별관계처럼 쓰이지않는다고 생각해서 비식별관계로 통일" 라는 코멘트가 남겨져 있는데 좀 더 부연설명을 해주셨으면 합니다. 맞냐 틀리냐를 떠나서 팀에서 어떻게 의사결정을 해서 이런 결과를 도출했는지 설명해주세요.

: 설계단계에서 비식별관계로 통일함으로써 부모entity의 키 변경이 자식entity에 영향을 미치지 않고, 변경사항이 생기면 더 유연하게 모델을 구축할 수 있다고 판단했습니다.

1. 리뷰 테이블에 이미지 컬럼이 있는데 타입 재확인 부탁드립니다.

: S3 콘솔에서 새로운 버킷을 만들고,MultipartFile 타입 을 이용해서 이미지를 받은후 해당 버킷에 업로드 한후, 이미지의 S3 버킷 URL을 얻어내어저장하고 있습니다.

1. 채팅메세지 테이블에 user_id column이 1개만 있는데 수신자 id를 저장하나요 아니면 발신자 id를 저장하나요? 유효한 컬럼인지도 검토 부탁드립니다.

: 채팅메시지 테이블의 id컬럼은 Chat Entity에 대한 개인키 컬럼이고, 기존에 있던 user_id 컬럼은 수신자와 발신자가 1:1로 채팅을 하기 때문에, 서로 발신자id에 대한 컬럼만 존재하면 되기때문에 sender_id로 컬럼을 수정하였습니다.

기술질문

1. OpenAPI를 사용해 책 가격을 가져올 때 어떤 플랫폼을 이용하셨고 왜 그런 선택을 했나요?

: