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

👩🏻‍💼 요구사항

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

1. 회원 목록 조회
2. 회원 조회
3. 회원 등록
4. 회원 수정
5. 회원 삭제

---

👷🏻 API URI 설계1

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

1. 회원 목록 조회 - /read-member-list
2. 회원 조회 - /read-member-by-id
3. 회원 등록 - /create-member
4. 회원 수정 - /update-member
5. 회원 삭제 - /delete-member

---

📌 API URI 설계 시 포인트

• URI 설계시 리소스와 행위를 분리하는 해야 한다. 가장 중요한 것은 리소스 식별이다.
• 리소스란?
  • 동작을 제외한 자원 그 자체를 리소스라한다.
  • 회원 등록 시스템을 예로 들면, 회원을 등록하거나 수정 혹은 삭제하는 행위는 리소스가 아니다.
  • 오직 회원이라는 개념만이 리소스라 할 수 있다.
  • 미네랄을 캐다! → 미네랄이 리소스.

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

• 리소스 : 회원 → 명사
• 행위 : 조회, 등록, 삭제, 변경 → 동사

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

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

3) 리소스 기반의 회원 관리 URI 설계

• 동작은 HTTP 메서드로 구분한다.(Ex: GET, POST, PUT, PATCH, DELETE, ...)

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

---

👷🏻 API URI 설계2

리소스 식별, URI 계층 구조를 생각하고 재설계해 보자.

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

계층 구조상 상위 자원을 컬렉션으로 보기에 복수형을 사용하는게 좋다. Ex: member → members

Ex: member → members

 

API URI 재설계를 했지만 행위는 구분이 되지 않는다. 구분하는 방법은 URI 리소스만 식별해 놓으면 HTTP 메서드인 GET, POST, PUT, DELETE 이런 것들이 조회, 등록, 수정, 삭제 역할을 대신해준다.

---

🙋🏻‍♂️ Q&A

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

 

A. 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

 

참고 : https://hseungyeon.tistory.com

 

위 자료는 김영한님의 ‘모든 개발자를 위한 HTTP 웹 기본 지식’ 강의를 참고하여 작성하였습니다.
https://www.inflearn.com/course/http-웹-네트워크/dashboard