HTTP 메서드(PUT, PATCH) & 메서드 속성

인프런 강의 中 
김영한 강사님의 '모든 개발자를 위한 HTTP 웹 기본 지식' 내용을 정리했습니다.

이미치 출처: https://www.inflearn.com/course/http-%EC%9B%B9-%EB%84%A4%ED%8A%B8%EC%9B%8C%ED%81%AC#

 

주말에도 공부를 하고자 블로그 포스팅 중인 웅쓰입니다. 최근 네트워크 관리사 시험이 끝나고 별다른 목표 없이 공부를 해오는 중이라 쉬엄쉬엄 했는데, 오늘 드디어! 또 다른 목표가 생겼습니다! 그 목표를 향해 열심히 또 달려보겠습니다 화이팅~! 오늘은 지난 시간에 정리했던 POST, GET 메서드에 이어 다른 메서드들과 HTTP 메서드의 속성을 김영한 강사님의 강의를 들으며 정리해보겠습니다.

 

목차

• HTTP API를 만들어보자.
• HTTP 메서드 - GET, POST
• HTTP 메서드 - PUT, PATCH, DELETE
• HTTP 메서드의 속성

1. HTTP 메서드 - PUT, PATCH, DELETE

 

(1). PUT

리소스를 대체하는 기능을 하며 메시지 body를 이용해 요청 데이터를 전달한다. 만약 요청한 데이터가 기존에 존재한다면 대체, 존재하지 않는다면 생성해주는 기능이다. 쉽게 말해서 리소스를 덮어버리는 기능이다. 

위 설명처럼 PUT은 기존에 리소스가 있는지 식별을 하는 순서가 있는데, 이는 클라이언트가 리소스의 위치에 해당하는 전체 경로를 알고 있다는 뜻이다. 즉, PUT은 클라이언트가 리소스의 전체 경로를 알고 있을때 사용하는 메서드이다.

 

클라이언트가 서버로 PUT 요청을 했을 때 기존 리소스가 대체되는 모습을 순서대로 살펴보겠다.

 

클라이언트 PUT 요청

클라이언트 PUT 요청

 

위 모습은 클라이언트가 요청 데이터(age: 50)를 PUT 요청으로 서버에 전달한 모습이다. 우선 앞서 말했듯 요청 URI을 보면 /members/100으로 클라이언트가 리소스의 위치 경로를 정확하게 지정하여 전달한 것을 확인할 수 있다. 그리고 해당 경로를 서버단에서 확인하면 username: young, age: 20이라는 리소스가 존재하는 것 또한 확인할 수 있다.

 

서버 리소스 대체

PUT 요청으로 인해 서버에서 리소스가 대체되는 모습

 

PUT 요청을 받은 서버단에서는 기존의 리소스가 완!전!히! 대체되어 버리는 모습을 확인할 수 있다. PUT은 이렇게 리소스를 덮어버리기 때문에 수정의 기능으로 생각하고 사용하면 안된다.(주의)

 

그럼 수정의 기능을 하는 메서드는 없을까? 흠... 바로

 

(2). PATCH

수정의 기능을 하는 메서드는 바로 PATCH이다. 리소스의 부분을 변경해주는 메서드이다. PATCH도 PUT과 마찬가지로 클라이언트가 리소스의 전체 경로를 알고 있을때 사용하는 메서드이다.

 

클라이언트가 PATCH로 부분 수정을 요청 했을 때 모습을 순서대로 확인해보자.

 

클라이언트 PATCH 요청

클라이언트 부분 수정 요청(PATCH)

 

클라이언트가 메시지 body에 요청 데이터(age: 50)을 담아서 서버에 수분 수정을 요청한 모습이다. 이때, PATCH 또한 리소스의 전체 경로를 알고 URI를 전송한 모습을 확인할 수 있다. 그리고 해당 경로를 서버단에서 확인하면 username : young, age: 20이라는 리소스가 존재한다는 것을 확인할 수 있다.

 

서버 리소스 부분 수정

서버 리소스 부분 수정

 

서버가 기존 리소스를 덮어버리지 않고 age만 50으로 수정한 모습을 확인할 수 있다. 이처럼 수정으로써의 기능을 할 때는 PATCH 메서드를 사용하면 된다.

 

※ 하지만 PATCH 또한 GET 요청의 메시지 body처럼 사용하지 못하는 서버가 있다. 그런 경우에는 우리에게 만능인 메서드 POST를 사용하면 된다. 필자는 그냥 어느정도는 URI로 기능을 식별하고 메서드는 POST로 쓰는게 나을 것 같다는 생각을 한다...ㅎ(오로지 개인적인 생각)

 

(3). DELETE

말 그대로 삭제 기능을 하는 메서드이다. 클라이언트가 DELETE로 삭제 요청을 했을 때 리소스가 삭제되는 모습을 순서대로 확인해보자.

 

클라이언트 DELETE 요청

클라이언트 삭제 요청(DELETE)

서버 리소스 삭제

서버 해당 리소스 삭제

 

 

2. HTTP 메서드 속성

메서드별 속성 요약표

참조: https://ko.wikipedia.org/wiki/HTTP

 

RFC 9110에 기반한 메서드 속성 요약표이다. RFC 9110에서는 GET 요청에 Body가 존재할 수 있나보다. 하지만 Body를 사용할 수 없는 버전도 있으니 주의!! 

그리고 안전, 멱등, 캐시 가능이라는 속성이 나와있는데 한번 정리해보자.

 

안전(safe)

안전한 속성을 가진 메서드는 호출해도 리소스를 변경하지 않는 메서드를 말한다. 만능 메서드라고 했던 POST나 이번 시간에 배웠던 PUT, PATCH, DELETE 등은 전부 리소스를 변경하는 메소드이기 때문에 안전한 메서드라고 할 수 없다. 안전한 메서드는 GET과 같이 조회를 하는 메서드가 안전한 메서드이다.

 

멱등(Idempotent)

f(f(x)) = f(x)라는 공식을 가지는 속성이다. 한 번 호출하든 두 번 호출하든 100번 호출하든 결과가 똑같다는 뜻이다.

• GET: 한 번 조회하든, 두 번 조회하든 같은 결과가 조회된다.
• PUT: 결과를 대체한다. 따라서 같은 요청을 여러번 해도 최종 결과는 같다.
• DELETE: 결과를 삭제한다. 같은 요청을 여러번 해도 삭제된 결과는 같다.
• POST: 두 번 호출하면 중복으로 인해 다른 결과가 발생할 수 있다.(EX. 같은 결제를 두 번 하면 돈이 두 번 빠져나감.) 고로 POST는 멱등인 메서드가 아니다!!!

멱등인 속성은 자동 복구 메커니즘에 사용된다. 서버가 TIMEOUT 등으로 정상 응답을 못주었을 때, 클라이언트가 같은 요청을 다시 해도 되는가?에 대한 판단 근거가 되어주는 중요한 속성이다. 즉, GET, PUT, DELETE 같은 경우는 서버 오류로 인한 자동 재요청이 가능한 메서드인 것이다.

 

※ 멱등은 외부 요인으로 중간에 리소스가 변경되는 것까지는 고려하지 않는다.(EX. 사용자1이 데이터를 조회할 때 중간 중간에 사용자2가 데이터를 수정하는 것은 고려하지 않음.)

 

캐시가능(Cacheable)

응답 결과 리소스를 캐시해서 사용해도 되는지에 관한 속성이다. 위 요약표에서는 POST도 된다고 나와 있지만 본문 내용까지 캐시 키로 고려해야 하는데, 이는 구현이 쉽지 않으므로 실제로는 GET, HEAD 정도만 캐시로 사용한다.

 

 

HTTP 메서드 속성 같은 경우에는 RFC 버전에 따라 메서드가 할 수 있는 기능이 다를 것이다. 이에 대한 것은 항상 잘 찾아보며 사용하자!

 

 

 

 

김영한 강사님 강의!!

https://www.inflearn.com/course/http-%EC%9B%B9-%EB%84%A4%ED%8A%B8%EC%9B%8C%ED%81%AC

모든 개발자를 위한 HTTP 웹 기본 지식 | 김영한 - 인프런