요구사항 - 회원 정보 관리 API를 만들기
- 회원 목록 조회
- 회원 조회
- 회원 등록
- 회원 수정
- 회원 삭제
잘못된 API URI 설계
- 회원 목록 조회 /read-member-list
- 회원 조회 /read-member-by-id
- 회원 등록 /create-member
- 회원 수정 /update-member
- 회원 삭제 /delete-member
가장 중요한 것은 리소스 식별
API URI 고민
- 리소스의 의미는 뭘까?
- 회원을 등록하고 수정하고 조회하는게 리소스가 아님
- ex) 미네랄을 조회하기 -> 회원이 리소스
- 회원이라는 개념 자체가 바로 리소스
- 리소스를 어떻게 식별하는게 좋을까?
- 회원을 등록하고 수정하고 조회하는 것을 모두 배제
- 회원이라는 리소스만 식별하면 된다. -> 회원 리소스를 URI에 매핑
API URI 설계 -- 리소스 식별, URI 계층 구조 활용
- 회원 목록 조회 /members
- 회원 조회 /members/{id}
- 회원 등록 /members/{id}
- 회원 수정 /members/{id}
- 회원 삭제 /members/{id}
- 계층 구조상 상위를 컬렉션으로 보고 복수단어 사용 권장(member -> members)
리소스와 행위을 분리 가장 중요한 것은 리소스 식별 -- URI는 리소스만 식별
- 리소스와 해당 리소스를 대상으로 하는 행위을 분리
- 리소스 -- 회원
- 행위 -- 조회, 등록, 삭제, 변경
- 리소스는 명사, 행위는 동사 (미네랄을 캐라)
- 행위(메서드)는 어떻게 구분? HTTP 메서드를 통해
'HTTP 웹 기본 지식' 카테고리의 다른 글
HTTP 메서드[PUT, PATCH, DELETE] (0) | 2022.11.24 |
---|---|
HTTP 메서드[GET, POST] (0) | 2022.11.24 |
HTTP 기본[HTTP 메시지] (0) | 2022.11.24 |
HTTP 기본[비 연결성(connectionless)] (0) | 2022.11.23 |
HTTP 기본[Stateful, Stateless] (0) | 2022.11.23 |
댓글