유저 검색 기능을 API로 설계할 때 두가지 방법이 있다
users/search/{name}
users/name=?
PathVariable을 쓸 것인가 Query Param을 쓸 것인가
https://hyeonproject.medium.com/path-parameter%EC%99%80-query-parameter%EC%97%90-%EB%8C%80%ED%95%B4%EC%84%9C-%EC%83%9D%EA%B0%81%ED%95%B4%EB%B3%B4%EA%B8%B0-143660b839c9
필수로 요구되는 값과 관련있을 때는 Path Param을 사용하고, 필수가 아니고 옵션일 경우에는 Query Param을 추천한다.
그냥 취향차이이긴 하지만 여러팀원이 모였을 땐 역시 다양한 의견이 생기는 것 같다 그래서 Rest API에 대한 관심이 생겼다.
Rest API 어떻게 하면 잘 설계할 수 있을까?
https://www.youtube.com/watch?v=ZuJUk9c2Ujs
위의 유투브를 한번 봐야겠다
Rest API는 기본적으로 HTTP프로토콜에서 사용된다 HTTP는 클라이언트와 서버간의 데이터를 주고받기 위해 사용되는 표준이다.
웹(HTTP)의 장점을 최대한 활용할 수 있는 아키텍처-> REST 아키텍처
Restful API는 요청메시지만 보고도 무엇을 원하는지 파악이 가능!
즉 자원의 이름으로 자원의 상태를 전달한다
Rest API 설계원칙
https://velog.io/@tiger/API-RESTful-API
위의 벨로그에서 가져왔습니다
Rest API 설계규칙
의미를 바로 알아볼 수 있도록 작성하고, 소문자를 사용한다.
❌ GET /users/writing
❌ GET /users/Post-Comments
⭕ GET /users/post-comments
URI가 길어지는 경우 언더바(_) 대신 하이픈(-)을 사용한다.
❌ GET /users/profile_image
⭕ GET /users/profile-image
마지막에 슬래시(/)를 포함하지 않는다.
후행 슬래시(/)는 의미가 전혀 없고 혼란을 야기할 수 있다.
❌ GET /users/
⭕ GET /users
리소스에 대한 행위를 HTTP Method로 표현한다.
URI에 HTTP Method가 포함되서는 안된다.
❌ get/users/
⭕ GET /users/
resource는 동사가 포함되서는 안되고 명사를 사용한다.
❌ GET /users/show/1
⭕ GET /users/1
파일 확장자는 URI에 포함시키지 않는다.
❌ GET /users/photo.jpg
⭕ GET /users/photo (이때, payload의 포맷은 headers에 accept를 사용한다.)
URI 사이에 연관 관계가 있는 경우 /리소스/고유ID/관계 있는 리소스 순으로 작성한다.
❌ GET /users/profile/{user_id}
⭕ GET /users/{user_id}/profile
URI에 작성되는 영어를 복수형으로 작성한다.
❌ GET /product
⭕ GET /products
URI는 / 구분자를 사용하여 자원의 계층 관계를 나타내는데 사용한다.
