[모든 개발자를 위한 HTTP 웹 기본 지식] 04. HTTP 메서드 - HTTP API를 만들어보자

(인프런) 김영한님의 모든 개발자를 위한 HTTP 웹 기본 지식을 공부하고 리뷰한 글입니다.

1. HTTP API를 만들어보자

1. 요구사항

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

1) 회원 목록 조회

2) 회원 조회

3) 회원 등록

4) 회원 수정

5) 회원 삭제

 

2. API URI 설계1

API 기능에 대응하는 직관적인 이름으로 URI 를 설계하면, 다음과 같이 URL을 모두 따로 만들어야 한다.

1) 회원 목록 조회 - /read-member-list

2) 회원 조회 - /read-member-by-id

3) 회원 등록 - /create-member

4) 회원 수정 - /update-member

5) 회원 삭제 - /delete-member

 

3. 이것은 좋은 URI 설계일까?

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

 

4. API URI 고민

1) 리소스의 의미

- 회원을 등록, 수정, 조회하는 것은 리소스가 아니다!!

- 회원이라는 개념 자체가 리소스다!

 

2) 리소스 식별 방법

- 회원을 등록, 수정, 조회하는 것을 모두 배제한다.

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

 

5. API URI 설계2

리소스 식별, URI 계층 구조 활용

1) 회원 목록 조회 /members

2) 회원 조회 /members/{id}

3) 회원 등록 /members/{id}

4) 회원 수정 /members/{id}

5) 회원 삭제 /members/{id} 

회원이라는 리소스를 URI에 매핑하면, 회원 조회/등록/수정/삭제의 URI가 /members/{id}로 동일하여 구분할 수가 없다는 문제가 생긴다.

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

 

6. 리소스와 행위를 분리

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

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

- 리소스: 회원 → 명사

- 행위: 조회, 등록, 삭제, 변경 → 동사

2) URI로 리소스를 표현해야 한다.

3) 리소스에 대한 행위는 HTTP Method(GET, POST, PUT, DELETE)로 표현된다.

 

[참고] https://bentist.tistory.com/37

 

---

4-1. HTTP API를 만들어보자 질문 정리

Q. members/1 이 아니라 members?id=1 이런식으로 써야하는 거 아닌가?

path와 query는 리소스를 식별하기 위해 함께 쓰인다.

query를 써서 members?id=1과 같이 사용할 수도 있지만 관례적으로 리소스를 식별할 때 id(식별자)는 members/1과 같이 path를 사용한다.

path는 주로 계층구조로 된 정보를 포함하고 query는 주로 비계층구조로된 정보를 포함한다.

즉, path는 리소스의 위치를 특정해서 보여줘야 하는 경우 사용하고, query는 리소스를 정렬/필터해서 보여줘야하는 경우 사용한다.

- path →  /members/1

- query → ?members?occupation=programmer

[출처] https://www.inflearn.com/questions/517777

[참고] https://velog.io/@jcinsh/Query-string-path-variable