HTTP API를 만들기위해 예시로 만들어보자
회원 목록 API를 설계한다고 가정했을 떄 아래와 같은 경우는 올바른 API 설계일까??
(Before)
- 회원 목록 조회 /read-member-list
- 회원 조회 /read-member-by-id
- 회원 등록 /create-member
- 회원 수정 /update-member
- 회원 삭제 /delete-member
API URI 설계하는데 있어서 가장 중요한 것은 리소스 식별이다!
API URI의 고민
리소스의 의미란?
- 회원을 등록하고 수정하고 조회하는게 리소스가 아니다. ex) 메니랄을 캐라가 리소스가 아니고 미네랄 자체가 리소스다.
- 위에서는 회원이라는 개념 자체가 바로 리소스 이다.
리소스를 식별하는 방법은 회원을 등록하고 수정 조회하는 것들은 배제하고 회원이라는 리소스만 식별하면 된다.
→ 회원 리소스를 URI에 매핑
→ 회원 목록 조회, 회원 조회, 회원 등록, 회원 수정, 회원 삭제
(After)
계층 구조상 회원 목록 조회를 상위를 컬렉션으로 보고 복수 단어로 표현 member → members
- 회원 목록 조회 /members
- 회원 조회 /members/{id}
- 회원 등록 /members/{id}
- 회원 수정 /members/{id}
- 회원 삭제 /members/{id}
근데 다 똑같이 {id}로 들어오는데 구분은 어떻게 하는 걸까???
리소스와 행위를 분리
- 가장 중요한 것은 리소스를 식별하는 것
- URI는 리소스만 식별
- 리소스와 해당 리소스를 대상으로 하는 행위를 분리
- 리소스 : 회원
- 행위 : 조회, 등록, 삭제, 변경
- 리소스는 명사, 행위는 동사 ex) 미네랄을 캐라
- 행위(메서드)는 어떻게 구분? 이 역할을 하는 것이 HTTP 메서드 이다.
'Dev > HTTP' 카테고리의 다른 글
HTTP 메서드 종류 PUT, PATCH 그리고 DELETE (0) | 2021.05.23 |
---|---|
HTTP 메서드 종류 GET과 POST (0) | 2021.05.23 |
HTTP의 메시지 (0) | 2021.05.23 |
HTTP의 성격 Connectionless (0) | 2021.05.23 |
HTTP의 성질 Stateless (0) | 2021.05.13 |