이번엔 store와 course에 대한 이번주 top5들을 가져오는 api를 설계 하였다. 로직은 문제가 없었고, 이번에도 api naming에서 발이 묶였다. 먼저 store들과 course들을 한 api에서 호출하는 것은 ui에 묶이는 api설계일 것이라 생각했다. 또한 store는 자신의 지역을 기반으로 근처의 가게들에 대해 가져오기 때문에 location까지 추가해 주어야 했다. /stores/location/:location/top 따라서 store table 안의 location안의 top5 가게들을 가져오게 이렇게 store controller에 설계하였다. /courses/top 마찬가지로 course도 이렇게 설계하였다. 하지만 top이란 field는 stores와 cou

프로젝트를 진행하며 사용자 정보를 수정하는 api를 만들었다. 피그마에 명시된 화면은 이런식이다. get '/users/me' 내 정보 가져오기 patch '/users/nickname' 닉네임 수정하기 patch '/users/profile-image' 프로필 이미지 수정하기 delete '/users/profile-image' 프로필 이미지 삭제하기 patch '/users/comment-alarm/on' 댓글 알림 켜기 patch '/users/comment-alarm/off' 댓글 알림 끄기 patch '/users/update-alarm/on' 업데이트 알림 켜기 patch '/users/update-alarm/off'

프로젝트에서 가게, 가게리뷰, 가게 좋아요 관련 CRUD를 만들때 api 경로에 대한 지적을 받았다. REST API를 지켜야하는 이유는 RESTful API는 일관성 있는 디자인 원칙과 표준화된 방법을 따르기 때문에, 다른 개발자나 팀이 API를 이해하고 사용하기 쉽다. 따라서 일관성 있는 API 디자인은 코드의 가독성과 유지 보수성을 향상시키며 확장성과 유연성을 가진다. 나는 REST API를 공부했지만, 그에 맞지 않게 post, get, patch, delete만 나누어 주는 짓을 하고 있었다. 내가 작성한 REST API에 맞지 않는 api 경로 post /store 가게 생성 get /store/:storeUUID 가게 정보 가져오기 patch /store 가게 수정 delete /store/:storeUUID 가게 삭제 post /store/like 가게 좋아요 `delete /store/

REST API란? 이전에 개발을 할때는 REST API원칙을 지키지 않으며 개발을 해왔다. 사실 REST API가 뭔지도 잘 알지 못하고 그냥 서버의 url중 하나라고만 생각하고 있었다. 이번 프로젝트에서는 REST API원칙을 최대한 지켜가며 개발을 하고 있다. 먼저 API란 무엇인가? API는 Application Programming Interface의 약자로 응용프로그램에서 데이터를 주고 받기 위한 방법을 의미한다. 그럼 REST API란 무엇인가? REST API란 REST를 기반으로 만들어진 API를 의미한다. REST Representational State Transfer의 약자로 자원을 이름으로 구분하여 해당 자원의 상태를 주고받는 것을 의미한다. 즉 HTTP URI(Uniform Resource Identifier)를 통해 자원(Resource)을 명시하고, HTTP Method(POST, GET, PUT, DELETE, P