✴️ HTTP 메서드 - PUT, PATCH, DELETE
⚡️ PUT
- 리소스를 대체
- 리소스가 있으면 대체, 리소스가 없으면 생성
- 클라이언트가 리소스를 식별한다!
- 클라이언트가 리소스 위치를 알고 URI를 지정한다.
- POST와의 가장 큰 차이점.
➡️ POST의 경우, 요청 메세지에서 path를
/members까지만 지정한 후, 요청 메세지를 받은 서버에서 신규 리소스 식별자를 생성해 넘겨주어야만 정확한 리소스의 위치를 알 수 있다.
리소스가 있는 경우
요청 메세지의 URI에 해당하는 리소스가 이미 존재하는 경우, 요청 메세지 내 메세지 본문에 들어있는 데이터가 이미 존재하던 리소스를 완전히 대체한다.
리소스가 없는 경우
요청 메세지의 URI에 해당하는 리소스가 존재하지 않는 경우, 해당 URI에 리소스를 생성한다.
이때 리소스를 "완전히 대체" 한다는 것이 중요하다. 다음과 같은 예시를 보자.
PUT 요청 메세지를 보내는 URI에 존재하는 리소스를 보면 username과 age, 이렇게 두 개의 필드가 존재한다. 이와 달리 요청 메세지의 메세지 본문에 보내는 데이터는 age 하나만 가지고 있는 것을 확인할 수 있다.
클라이언트가 서버에게 PUT 요청 메세지를 보냈을 때 리소스를 완전히 대체하기 때문에, 해당 URI에 새롭게 생성된 메세지를 보면 username 필드가 삭제되고 age 필드만 있는 것을 확인할 수 있다.
만약 사용자의 의도가 리소스를 완전히 대체하는 것이 아니라 필드 일부분의 값 변경이었다면, PUT이 아니라 PATCH를 사용해야 한다.
⚡️ PATCH
- 리소스의 일부분을 변경
- PATCH 요청 메세지의 형태
PATCH를 사용한 요청 메세지를 보자.
사용자의 의도는 age 필드의 값을 50으로 변경하기 위함이다.
클라이언트와 위와 같이 PATCH 요청 메세지를 보내면, 서버에서 이를 받아 리소스의 부분만 변경하는 것을 확인할 수 있다.
일부 서버에서 PATCH 지원이 안될 가능성도 있는데, 그때는 POST를 사용하면 된다. (POST는 무적! ⭐️)
⚡️ DELETE
- 리소스 제거
DELETE 요청 메세지를 보내면 서버는 해당 리소스를 삭제하게 된다.
✴️ HTTP 메서드의 속성
- 안전(Safe Methods)
- 멱등(Idempotent Methods)
- 캐시 가능(Cacheable Methods)
⭐️ 안전(Safe)
- 호출해도 리소스를 변경하지 않는다.
- GET은 안전, POST, DELETE 등은 안전❌
- Q: 그래도 계속 호출해서, 로그 같은게 쌓여서 장애가 발생하면요?
- A: 안전은 해당 리소스만 고려. 장애 발생 가능성까지 고려하지 않는다.
⭐️ 멱등(Idempotent)
- f(f(x)) = f(x)
- 한 번 호출하든, 두 번 호출하든, 100번 호출하든 결과가 똑같다.
- 멱등 메서드
- GET: 한 번 조회하든, 두 번 조회하든 같은 결과가 조회된다.
- PUT: 결과를 완전히 대체한다. 따라서 같은 요청을 여러 번 해도 최종 결과는 같다.
- DELETE: 결과를 삭제한다. 같은 요청을 여러 번 해도 삭제된 결과는 똑같다.
- POST: 멱등이 아니다! 두 번 호출하면 같은 결제가 중복해서 발생할 수 있다.
🤔 어떻게 활용할 수 있는가?
"서버가 TIMEOUT 등으로 정상 응답을 못주었을 때, 클라이언트가 같은 요청을 다시 해도 되는가?"에 대한 판단 근거가 될 수 있다.- 또한, 멱등은 외부 요인으로 중간에 리소스가 변경되는 것까지는 고려하지는 않는다.
⭐️ 캐시 가능(Cacheable)
- 응답 결과 리소스를 캐시해서 사용해도 되는가?
- GET, HEAD, POST, PATCH가 캐시 가능하나, 실제로는 GET, HEAD 정도만 캐시를 사용한다. (실무에서는 거의 GET만!)
- POST, PATCH는 메세지 본문 내용까지 캐시 키로 고려해야 하는데, 구현이 쉽지 않기 때문이다.
- POST, PATCH는 메세지 본문 내용까지 캐시 키로 고려해야 하는데, 구현이 쉽지 않기 때문이다.
Reference
꾸준함이 무기