HTTP - PUT&PATCH&DELETE, HTTP 메소드의 속성

PUT

PUT /members/100 HTTP/1.1
Content-Type: application/json
{
  "username": "hello",
  "age": 20
}

• 리소스를 완전히 대체한다.
  • 리소스가 있으면 대체
  • 리소스가 없으면 생성
  • 쉽게 이야기해서 덮어버린다
• 중요한건 클라이언트가 리소스를 식별한다.
  • 클라이언트가 리소스 위치를 알고 URI를 지정한다.
  • 이 부분이 POST와 차이

리소스가 있는 경우

리소스가 없는 경우

리소스가 완전히 대체

PATCH

• 리소스 부분 변경

PATCH 과정

DELETE

• 리소스 제거

DELETE 과정

메시지가 서버에 도착하면 서버에서는 리소스를 제거한다.

HTTP 메소드의 속성

• 안전 (Safe Methods)
• 멱등 (Idempotent Methods)
• 캐시 가능 (Cacheable Methods)

안전(Safe)

• 호출해도 리소스를 변경하지 않는다!
• 그래도 계속 호출해서 로그가 쌓여 장애가 발생한다면?
  • 안전은 해당 리소스에 대한 것만 고려하기 때문에 그런 부분은 고려하지 않는다.

멱등(Idempotent)

• f(f(x)) = f(x)
• 한 번 호출하든 두 번 호출하든 100번 호출하든 결과가 똑같다.
• 멱등 메소드
  • GET : 한 번 조회하든, 두 번 조회하든 같은 결과가 조회단다.
  • PUT : 결과를 대체한다. 따라서 같은 요청을 여러번 해도 최종 결과는 같다.
  • DELETE : 결과를 삭제한다. 같은 요청을 여러번 해도 삭제된 결과는 똑같다.
  • POST : 멱등이 아니다. 두 번 호출하면 같은 결제가 중복해서 발생할 수 있다.
• 활용
  • 자동 복구 메커니즘
  • 서버가 TIMEOUT 등으로 정상 응답을 주지 못 했을 때, 클라이언트가 같은 요청을 다시 해도 되는가? 에 대한 판단 근거
    • 어차피 똑같은 요청을 여러번 해도 결과는 똑같기 때문
• 재요청 중간에 다른 곳에서 리소스를 변경하면?
  • 멱등은 외부 요인으로 중간에 리소스가 변경되는 것 까지는 고려하지는 않는다.

캐시 가능(Cacheable)

• 응답 결과 리소스를 캐시해서 사용해도 되는가?
• GET, HEAD, POST, PATCH 캐시 가능
  • 실제로는 GET, HEAD 정도만 캐시로 사용한다.
    • POST, PATCH는 본문 내용까지 캐시 키로 고려해야 하는데, 구현이 쉽지 않다.
      • 캐시를 하려면 똑같은 리소스랑 키가 맞아야 하는데, POST는 body안에 데이터까지 고려해야 하기 때문에 구현이 쉽지 않음.
    • GET은 URL만 키로 잡고 캐시를 하면 되기 때문에 간단하고 쉽다.

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