HTTP API

API URI 설계
요구사항 : 회원 정보 관리 API를 만들어라
- 회원 목록 조회 / read-member-list
- 회원 조회 / read-member-by-id
- 회원 등록 / create-member
- 회원 수정 / update-member
- 회원 삭제 / delete-member

이것은 좋은 URI 설계일까?
가장 중요한 것은 리소스 식별이다

리소스의 의미는 뭘까?
- 회원을 등록하고 수정하고 조회하는게 리소스가 아니다
- 예) 미네랄을 캐라 > 미네랄이 리소스
- 회원이라는 개념 자체가 바로 리소스이다

리소스를 어떻게 식별하는게 좋을까?
- 회원을 등록하고 수정하고 조회하는 것을 모두 배제
- 회원이라는 리소스만 식별하면 된다 > 회원 리소스를 URI에 매핑

위 지식을 동원해 다시 설계해 보자
- 회원 목록 조회 / members (계층 구조상 상위 컬렉션으로 보고 복수단어 사용 권장)
- 회원 조회 / members/{id}
- 회원 등록 / members/{id}
- 회원 수정 / members/{id}
- 회원 삭제 / members/{id}
이러면 구분을 어떻게 할까라는 문제가 생긴다

리소스와 행위를 분리하자
가장 중요한 것은 리소스를 식별하는 것이다
- URL은 리소스만 식별
- 리소스와 해당 리소스를 대상으로 하는 행위를 분리
 - 리소스 : 회원
 - 행위 : 조회, 등록, 삭제, 변경
- 리소스는 명사, 행위는 동사 (미네랄을 캐라)

행위(메서드)는 어떻게 구분할까?
그 해답이 바로 GET, POST 이다