HTTP 메서드

다음과 같은 회원 정보 관리 API를 만든다고 가정해보자

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

API URI를 다음과 같이 설계했다.

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

이것은 좋은 URI 설계일까?

 

이번 시간에는 URI 설계 기준과 HTTP Method, 그리고 HTTP Method의 속성에 대해서 알아보겠다.

 

---

URI 설계 기준

URI 설계 기준 = 1. 리소스 식별  2.URI 계층 구조 활용 

1. URI(Uniform Resource Identifier)는 이름 그대로 리소스를 식별하는 목적이다.

따라서 리소스를 대상으로 하는 '행위'를 URI에 넣는 것은 취지에 어긋난다.

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

 

리소스는 무엇을 의미하는가?

회원을 등록하고 수정하고 조회하는게 리소스가 아니다!

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

예를 들어 미네랄을 캐라 → 미네랄이 리소스!!

 

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

기능	URI
회원 목록 조회	/members
회원 조회	/members/{id}
회원 등록	/members/{id}
회원 수정	/members/{id}
회원 삭제	/members/{id}

그런데.. URI가 똑같다. 어떻게 구분할까?

 

리소스와 행위를 분리하라

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

 

URI는 리소스만 식별하고!

행위(동사)는 HTTP 메서드로 구분한다!

기본적으로는 리소스 URI로 설계해야 하지만, 리소스만으로 안될 때도 있다.
동사를 표현하기에 HTTP 메서드만으론 부족한 경우, URI에 동사를 표현하기도 한다(컨트롤 URI)
ex) POST /orders/{orderId}/start-delivery (이럴 땐 주로 POST 사용)

 

---

 

HTTP 메서드

클라이언트가 서버에게 기대하는 행동

 

HTTP 메서드의 종류

• 주요 메서드
  - GET: 리소스 조회
  - POST: 요청 데이터 처리, 주로 등록에 사용
  - PUT: 리소스 대체, 완전 변경.  해당 리소스가 없으면 생성 (덮어쓰기)
  - PATCH: 리소스 부분 변경 (ex. 패스워드만 바꿀 때)
  - DELETE: 리소스 삭제
  
  
• 기타 메서드
  - HEAD: GET과 동일하지만 메시지 바디 부분을 제외하고, 상태 라인과 헤더만 반환
  - OPTIONS: 대상 리소스에 대한 통신 가능 옵션(메서드)을 설명(주로 CORS에서 사용)
  - CONNECT: 대상 자원으로 식별되는 서버에 대한 터널을 설정
  - TRACE: 대상 리소스에 대한 경로를 따라 메시지 루프백 테스트를 수행

 

GET - 리소스 조회

1. 데이터는 쿼리파라미터로 전달

(메시지 바디를 사용해서 데이터를 전달할 수도 있지만, 지원하지 않는 곳이 많음)

2. 캐시 등을 지원

GET 메시지 전달

GET 메시지 응답

 

POST - 데이터 전달 > 처리

1. 메시지 바디로 데이터 전달

2. 서버는 요청 데이터 처리

   - 새 리소스 등록(생성)

   - 프로세스 처리

     > POST의 결과로 새로운 리소스가 생성되지 않을 수 있음.

     > 다른 메서드로 처리하기 애매한 경우. 컨트롤 URI. (ex. /orders/{orderId}/start-delivery)

3. PUT/PATCH/DELTE와의 차이 : 클라이언트는 리소스 위치를 모른 채 데이터를 보내고, 서버를 URI를 생성해서 알려줌.

요청 데이터 전달

요청 데이터 처리 (신규 리소스 생성)

응답 데이터 전달

 

PUT - 리소스 완전 변경

1. 리소스 덮어쓰기 (PATCH와 다르게)
    - 리소스가 있으면 대체, 없으면 생성

2. 클라이언트가 리소스 URI 지정 (POST와 다르게)

리소스가 없는 경우

클라이언트가 URI를 지정

없으면 생성

 

리소스가 있는 경우

덮어 쓴다. 삭제하고 새로 쓴다는 것에 주의하자.

 

주의! '완전히' 대체한다.

age 필드만 값을 바꾸고 싶었다

username 필드가 날라갔다ㅠㅠ

즉, PUT은 '수정'에 적합한 메서드가 아니다.

전체 데이터를 보낼 때야 덮어써도 상관없지만 그런 경우가 많지 않다.

부분적인 '수정'을 하고 싶다면..?

 

PATCH - 부분적인 수정

patch: (특히 주변과는 다른 조그만) 부분

 

리소스 부분 변경

age만 변경하고 싶다

부분적으로 수정되었다

 

 

DELETE - 리소스 제거

DELETE 메서드로 요청하면

 

 

 

 

Q. HTTP 메서드는 실제 동작하는가?

HTTP 메서드는 실제로 동작하는 건 아니다.

규칙이라고 생각하면 된다.

실제 동작은 개발자가 구현해야 한다.

 

---

 

HTTP 메서드의 속성

1. 안전 : 호출해도 대상 리소스를 변경하지 않는다
   GET, HEAD
   
   
2. 멱등 : 1번 호출하든 100번 호출하든 결과가 똑같다
   - GET, PUT, DELETE
   - POST는 아니다! 예를 들어 2번 호출하면 결제가 중복해서 발생할 수 있다.
   
   Q. 이런 성질을 왜 알아야 할까? 어떻게 활용되나?
   멱등한 메서드는 자동 복구 메커니즘에 활용할 수 있다!
   서버가 TIMEOUT 등으로 정상 응답을 못 주었을 때, 클라이언트가 같은 요청을 다시 해도 되는지 판단하는 근거
   
   ex) DELETE 호출했는데 서버 응답이 없어서 잘 됐는지 모르겠다.
   ▷ 클라이언트가 자동으로 DELETE 재시도
       그래도 괜찮다! 멱등하니까!
   
   
   
3. 캐시 가능 : 응답 결과 리소스를 캐시해서 사용해도 되는가?
   실제로는 GET, HEAD 정도만 캐시로 사용한다. (POST, PATCH도 가능하긴 함)
   ※ 캐시 KEY가 같아야 하는데, POST, PATCH는 BODY 내용까지 캐시 KEY로 고려해야 해서 복잡
   
   

 

---

 

참고 자료 & 이미지 출처
모든 개발자를 위한 HTTP 웹 기본 지식 (김영한 님)
컴퓨터 네트워킹 : 하향식 접근 7판 (JAMES F.KUROSE)