=> Request Param 에 따른 overrode를 할 수 없었기 때문에 {cafeId}와 {cafeId}/aftersearch 로 두 가지 API 엔드 포인트를 설정했으나, 이는 결코 RestFul 하지 않았다. 이를 방지 하기 위해서 프론트와 협의 이후 핫플레이스로 갈 경우 검색 이후 카페 찾기를 쓰기 위해 param을 일괄적으로 넣어주기로 하여 두 엔드포인트를 {cafeId}/table로 통합했다.
두번째 : 카페 디테일 내역 가져오기
카페 정보와 테이블을 한꺼번에 가져오는 로직을 구성했었는데, 이것이 실제로 API 요청을 더 많이 보낸다는 이야기를 받았다. 실제로 구성을 조금씩 바꿀 때마다 카페 디테일 정보를 지속적으로 받아오기 때문이다. 그래서 카페 디테일한 정보를 {cafeId}로 변경하기로 하였다.
세번쨰 : PeopleNumber 와 같은 경우 int 값으로 받았었다. 하지만 이는 참조 변수가 아니기 때문에 null 값을 가질 수 없었다. (heap 자체에 저장되는 부분이기 때문에. stack에 저장되는 것은 참조 값을 저장하기 때문에 null 값을 가질 수 있다.) 이를 Integer로 변경하였다.
✏️ Rest하게 API 를 통신할 수 있도록 변경
첫번째 : 카페 테이블 내역 가져오기 통합
핫플레이스 카페 찾기
검색 이후 카페 찾기
=> Request Param 에 따른 overrode를 할 수 없었기 때문에 {cafeId}와 {cafeId}/aftersearch 로 두 가지 API 엔드 포인트를 설정했으나, 이는 결코 RestFul 하지 않았다. 이를 방지 하기 위해서 프론트와 협의 이후 핫플레이스로 갈 경우 검색 이후 카페 찾기를 쓰기 위해 param을 일괄적으로 넣어주기로 하여 두 엔드포인트를 {cafeId}/table로 통합했다.
두번째 : 카페 디테일 내역 가져오기
세번쨰 : PeopleNumber 와 같은 경우 int 값으로 받았었다. 하지만 이는 참조 변수가 아니기 때문에 null 값을 가질 수 없었다. (heap 자체에 저장되는 부분이기 때문에. stack에 저장되는 것은 참조 값을 저장하기 때문에 null 값을 가질 수 있다.) 이를 Integer로 변경하였다.
🛠 Features
❗️Warnning