[모든 개발자를 위한 HTTP 웹 기본 지식] 4. HTTP 메서드

Network . ..............................................................................................................................................................................................................................................................................................................................................................................................................................................................................................

인프런 김영한 강사님의 [모든 개발자를 위한 HTTP 웹 기본 지식] 을 수강하고 정리한 글입니다.

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

 

📌 HTTP API 만들기

✅ 좋은 URI 설계

예를 들얼 회원 목록을 조회하는 API를 만든다 하자.

그렇다면 URI를 /read-member-list 이런식으로 작성하면 좋을까?

 

좋지 않다.

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

회원이라는 리소스만 URI에 매핑하고, 어떤 일을 수행하는지는 HTTP 메서드(Get, Post ...)를 통해 표현한다.

 

좋은 URI 설계는 결국 리소스와 행위를 분리하는 것이다.

URI는 리소스만 식별하고, 행위는 HTTP 메서드로 해결하자.

  

  

📌 HTTP 메서드

✅ HTTP 메서드 종류

GET : 리소스 조회

POST : 요청 데이터 처리 (보통 등록에 사용한다.)

PUT : 리소스 대체, 해당 리소스가 없으면 생성

PATCH : 리소스 부분 변경

DELETE : 리소스 삭제

------ 아래는 잘 사용하지는 않는 기타 HTTP 메서드들 -----

HEAD : GET과 동일한데 메시지를 제외한 상태 줄과 헤더만 반환한다.

OPTIONS : 대상 리소스에 대한 통신 가능 옵션(메서드) 설명 (보통 CORS에서 활용)

CONNECT : 대상 리소스로 식별되는 서버에 대한 터널 설정

TRACE : 대상 리소스에 대한 경로를 따라 메시지 루프백 테스트 수행

  

  

✅ GET

리소스 조회

 

서버에 전달하고 싶은 데이터는 query(쿼리 파라미터, 쿼리 스트링)을 통해 전달한다.

 

메시지 바디를 통해 전달할 수도 있지만 권장 X (지원 안하는 곳도 있음)

  

  

✅ POST

요청 데이터 처리

 

메시지 바디를 통해 서버로 요청 데이터를 전달하고, 서버는 받은 요청 데이터를 처리해서 응답한다.

결국 서버는 요청 데이터를 어떻게 처리할 지 정해진 것이 없기 때문에 리소스마다 따로 정해야 된다.

 

신규 리소스 등록, 프로세스 처리 등에 사용한다.

다른 메서드로 처리하기 애매한 경우 그냥 POST를 범용적으로 사용하기도 한다.

  

  

✅ PUT

리소스를 덮어버린다.

리소스가 있으면 대체하고, 없으면 생성한다.

 

PUT은 POST와 다르게 클라이언트가 리소스를 식별한다. (서버에 요청할 때 이미 클라이언트가 리소스를 알고 URI에 지정한다.) 이는 POST와의 차이점이며, HTTP API를 설계할 때 고려사항이 된다.

  

  

✅ PATCH

PUT과 무언가를 수정한다는 점에서 비슷해보이지만,

PATCH는 완전히 덮어버리는 것이 아니라, 변경하고 싶은 부분만 부분변경한다.

  

  

✅ DELETE

리소스 제거

  

  

📌 HTTP 메서드의 속성: 안전, 멱등, 캐시 가능

HTTP 메서드들의 속성을 한 눈에 볼 수 있는 표

 

✅ 안전(Safe Methods)

해당 HTTP 메서드를 호출하더라도 리소스를 변경하지 않는 특성을 의미한다.

 

의문점
Q. 지속적으로 호출하여 로그가 쌓여서 발생하는 장애의 경우 안정적이지 않다고 판단하는가?
A. 안전 특성은 해당 리소스만 고려하지, 그러한 추가 상황은 고려하지 않는다.

  

  

✅ 멱등(Idempotent Methods)

멱등성

몇 번을 호출하든 결과가 같은 것을 의미한다.

 

GET, PUT, DELETE는 멱등성을 띄고, POST는 그렇지 않다.

PUT의 경우, 기존 것을 날리고 완전히 덮어버리기 때문에 몇 번을 호출하든 결과가 같다.

POST의 경우, 여러번 호출하면 다른 이슈가 발생할 수도 있다. ex> 두 번 결제를 호출하게 되어 같은 결제가 중복 발생

 

이러한 멱등의 특징을 활용한 시스템이 있다.

 

자동 복구 메커니즘인데, 서버에서 응답이 제 때 오지 않는 TIMEOUT 발생 시, 클라이언트가 같은 요청을 하더라도 결과가 달라지지 않기 때문에 같은 요청을 추가로 진행 할 수 있다. 

 

의문점
Q. 멱등을 활용한 재 요청 중간에 다른 곳에서 리소스를 변경해버리면 어떻게하지? 결과가 달라질 수 있지 않나?
A. 멱등은 외부 요인으로 인한 리소스 변경은 고려하지 않는다.

  

  

 

✅ 캐시 가능(Cacheable Methods)

응답 결과 리소스를 캐싱해서 사용해도 된다는 것을 의미한다.

 

GET, HEAD, POST, PATCH는 캐시 가능인데, 실제로는 GET, HEAD 정도만 캐시로 사용한다.

POST와 PATCH는 캐싱이 가능하더라도 구현 자체가 어렵기 때문에 잘 사용하지 않는다.