HTTP API 를 만들어보자 - URI 설계

요구사항

회원 정보 관리 API를 만들어라.

- 회원 목록 조회 => 만약 /read-member-list 로 한다면?
- 회원 조회 => 만약 /read-member-by-id 로 한다면?
- 회원 등록 => 만약 /create-member 로 한다면?
- 회원 수정 => 만약 /update-member 로 한다면?
- 회원 삭제 => 만약 /delete-member 로 한다면?

URI 설계에서 가장 중요한 것은 리소스 식별이다.

 

리소스의 의미는 뭘까?

회원을 등록하고 수정하고 조회하는게 리소스가 아니다! 

예) 미네랄을 캐라 <- 리소스 아님
캐라 <- 리소스 아님
미네랄 <- 리소스

요구사항에서는, 회원이라는 개념 자체가 바로 리소스다

리소스와 행위를 분리

행위를 판단하는데 URI 를 사용하면 안됨

 

리소스를 어떻게 식별하는게 좋을까?

회원을 등록하고 수정하고 조회하는 것을 모두 배제

회원이라는 리소스만 식별하면 된다. -> 회원 리소스를 URI에 매핑

 

API URI 설계

URI 에서 리소스 식별하고, URI 계층 구조를 활용

회원 목록 조회 /members
회원 조회 /members/{id}
회원 등록 /members/{id}
회원 수정 /members/{id}
회원 삭제 /members/{id}

참고: 계층 구조상 상위를 컬렉션으로 보고 복수단어 사용 권장(member -> members)

하지만 조회, 등록, 수정, 삭제를 어떻게 구분하는가?

 

리소스와 행위를 분리

URI 설계에서 가장 중요한 것은 리소스를 식별하는 것

리소스와 해당 리소스를 대상으로 하는 행위을 분리

리소스: 회원

행위: 조회, 등록, 삭제, 변경

리소스는 명사, 행위는 동사 에 비유할수 있다.

 

행위는 어떻게 구분? => HTTP 메서드