[HTTP 메서드] HTTP API

회원 정보 관리 API 만들어보기

• 회원 목록 조회
• 회원 조회
• 회원 등록
• 회원 수정
• 회원 삭제

API URI(Uniform Resource Identifier) 설계

• 회원 목록 조회 /read-member-list
• 회원 조회 /read-member-by-id
• 회원 등록 /create-member
• 회원 수정 /update-member
• 회원 삭제 /delete-member

위처럼 설계했다면,, ⛔ 과연 이것이 좋은 URI 설계인가..?

⭐가장 중요한 것은 리소스 식별!⭐

• 리소스의 의미는?
  • 회원을 등록하고 수정하고 조회하는게 리소스가 아니다!
  • 예) 미네랄을 캐라 -> "미네랄"이 리소스
  • 즉, "회원"이라는 개념 자체가 바로 리소스다
• 리소스를 어떻게 식별하는게 좋을까?
  • 회원을 등록하고 수정하고 조회하는 것을 모두 배제
  • "회원"이라는 리소스만 식별하면 된다 -> 회원 리소스를 URI에 매핑

리소스 식별, URI 계층 구조 활용하여 다시 설계해본다면,

• 회원 목록 조회 /members
• 회원 조회 /members/{id}
• 회원 등록 /members/{id}
• 회원 수정 /members/{id}
• 회원 삭제 /members/{id}
• 참고: 계층 구조상 상위를 컬렉션으로 보고 복수단어 사용 권장 (member->members)

⛔ 조회, 등록, 수정, 삭제 URI가 같은데 어떻게 구분할까?

=> 리소스와 행위를 분리

가장 중요한 것은 리소스를 식별하는 것

• URI는 리소스만 식별
• 리소스는 해당 리소스를 대상으로 하는 행위를 분리
  • 리소스 : 회원
  • 행위 : 조회, 등록, 삭제, 변경
• 리소스는 명사, 행위는 동사 (미네랄을 캐라)
• 행위(메서드)는 어떻게 구분? -> HTTP 메서드!!!!