HTTP API

API 설계를 해보자.

• 회원 목록 조회

 

• 회원 조회

 

• 회원 등록

 

• 회원 수정

 

• 회원 삭제

 

아래의 좋지 않은 설계를 보자.

• 회원 목록 조회 / read-member-list

 

• 회원 조회 / read-member-by-id

 

• 회원 등록 /  creadte-member

 

• 회원 수정 / update-member

 

• 회원 삭제 / delete-member

 

 

가장 중요한 것은 리소스 식별이다.

• API URI 고민

 

• 리소스의 의미는?

 

• 회원을 등록하고 수정하고 조회하는게 리소스는 아님

 

• 회원이라는 개념 자체가 바로 리소스

 

• 리소스를 어떻게 식별할까

 

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

 

• 회원이라는 리소스만 식별하자.

 

• 회원 리소스를 URI에 매핑

 

 

리소스 식별, URI 계층 구조 활용(URI 설계는 리소스 식별 + URI 계층 구조로 설계 하는것이 제일 중요)

 

• members

 

• members/{id}

 

• members/{id}

 

• members/{id}

 

• members/{id}

 

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

 

 

=> ? 근데 이걸 어떻게 구분하지?

 

 

 

리소스와 행위를 분리하자!

 

 

중요한 것은 리소스를 식별하는 것이다.

URI는 리소스만 식별

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

 

 

• 리소스: 회원

 

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

 

리소스는 명사, 행위는 동사

 

 

행위(메서드)는 어떻게 구분할까?

 

 

 

GET, POST 방식에서 알아보자.

 

 

 

 

 

 

 

 

 

 

 

<출처 김영한: 모든 개발자를 위한 HTTP 웹 기본 지식 >

https://www.inflearn.com/course/http-%EC%9B%B9-%EB%84%A4%ED%8A%B8%EC%9B%8C%ED%81%AC/dashboard

모든 개발자를 위한 HTTP 웹 기본 지식 - 인프런 | 강의