feat : 지점 조회, 찜 관련하여 추가 요구사항 반영

[zuminzi]

cf. 2023.04.07 추가된 찜 삭제 동시성에 관한 커밋은 잘못 매치된 커밋. #76 가 올바른 이슈넘버

목적

지점 조회, 찜 관련하여 수정된 디자인 반영

작업 상세 내용

• Shop, Favorite 성공 응답구조 수정
• [x] RsData(공통 응답 바디 DTO)에 result 매개변수만 있는 생성자 오버로딩
• [x] RsData 성공여부 필드(success) boolean에서 Boolean으로 타입 수정
• [x] Get 요청은 실질적으로 사용하는 결과값만 ResponseEntity 바디에 담아 응답
• [x] Put, Delete 요청은 응답 바디 생략
• 성공 시 디폴트 상태코드 200, 상태코드 따로 지정하고 싶다면 @ResponseStatus
• 불필요한 검사 코드 제거
• [x] 응답시간 개선을 위해 브랜드별 조회 대표브랜드 여부 체크하는 로직 제거
• 프론트에서 넘기는 브랜드 파라미터 유효성 체크는 @NotEmpty로 충분
• 찜 목록 페이지 응답값 추가
• [x] 사용자의 현재 위도, 경도 요청 파라미터에 추가
• [x] Kakao Map 호출 코드 추가
• [x] 상세페이지와 마찬가지로 유효하지 않은 shop-id는 결과값을 반환할 수 없기 때문에 찜 목록 조회에서도 유효하지 않은 shop-id 예외 처리
• 찜 추가 시에도 유효한 shop-id인지 검사하려면 카카오 API 호출하여 검사 필요(비효율적). 이 문제는 실 서비스가 아닌 API 테스트 시에만 발생하는 문제이기 때문에 찜 추가 후 찜 목록 조회 시 유효하지 않은 shop-id는 자동 찜 취소처리
• [x] DB 장소명 Kakao API 장소명 반영
• [x] 리뷰 개수, 평점, 찜 수, 현재위치로부터의 거리 추가
• 찜 수
• [x] 찜 수 필요한 API에 응답값 추가
• 간단 조회 페이지(Map Marker 모달용), 상세 페이지
• [x] 회원 별 찜 수 20개로 개수 제한

  참고 사항

  I. RsData 성공여부 필드(success) boolean에서 Boolean으로 타입 수정한 이유 -> 프론트 측에서 RsData로 감싸지 않는 응답구조 요청

• 성공 시(200) 바디로 넘기는 데이터 중 success, message 필드는 활용하지 않는다는 프론트 답변
• 그러나 boolean 타입은 RsData 클래스 생성자 매개변수로 주어지지 않을 시 null이 아닌 false로 초기화
• 클래스에 적용된@JsonInclude(JsonInclude.Include.NON_NULL)에 의해 null 필드만 제외되므로
• boolean 타입은 필요 없는 경우에도 응답에서 제외되지 않음

결론

성공 여부 필드가 주어지지 않았을 경우 null로 초기화하여 응답 바디에서 제외되도록

II. 찜 목록 페이지에서 요청 파라미터 중 criteria는 @ModelAtttribute 이용하여 DTO로 관리하지 않은 이유

1. 특정 default value 세팅 옵션은 @RequestParam만 가능하므로
   • @ModelAtttribute는 따로 지원하지 않기 때문에 criteria가 매개변수로 주어지지 않는 생성자 메서드에서 원하는 초기값 따로 세팅 필요
2. 쿼리 파라미터명과 속성값을 분리하기 위해 (sort=criteria)
   • @ModelAtttribute는 모델명과 매개변수명이 일치할 경우 바인딩
   • 참고자료
   • Spring MVC와 @ModelAttribute 어노테이션
   • @ModelAttribute에서 default value

     III. 찜 추가 개수 초과시 상태코드

     Kakao Developers REST API 공식문서와 상태코드 관련 자료 검색 결과 API 요청 횟수 초과 시 429, 리소스 개수 초과 시 400 HTTP Status Code를 반환하는 것으로 확인했습니다.

따라서 찜 개수 초과 시에도 400 에러를 응답하도록 구현하였습니다.