반응형
# 모든 개발자를 위한 HTTP 웹 기본 지식 학습
# HTTP 메서드
## PUT
- 리소스를 대체한다.
리소스가 있으면 대체
리소스가 없으면 생성
=>
쉽게 얘기하면 덮어버림- 중요! 클라이언트가 리소스를 식별한다.
클라이언트가 리소스 위치를 알고 URI를 지정한다.
(POST와 다른점)### PUT1 - 리소스가 있는 경우 1
- 클라이언트가 /members 100번에 리소스를 넣을 것이라고 지정하고 데이터를 보낸다.
PUT/members/100 HTTP/1.1
Content-Type: application/json
{
"username":"old",
"age":50
}- 서버에서 확인했을 때 /members 100번에 이미 데이터가 존재한다면,
/members/100
{
"username":"young",
"age":20
}### PUT - 리소스가 있는 경우 2
- 서버에 있는 리소스가 클라이언트로부터 받은 리소스로 대체가 된다.
/members/100
{
"username":"old",
"age":50
}### PUT - 주의!! 리소스를 완전히 대체한다 1
- /members 100번에 age만 업데이트 하고 싶은 경우..
PUT/members/100 HTTP/1.1
Content-Type: application/json
{
"age":50
}- 서버에 있는 리소스가..
/members/100
{
"username":"young",
"age":20
}### PUT - 주의!! 리소스를 완전히 대체한다 2
- 클라이언트가 보낸 리소스로 대체되면서 기존 username 필드가 삭제된다.
- 이와 같은 문제 해결 위해서는 PATCH 사용.
/members/100
{
"age":20
}## PATCH
- 리소스를 부분 변경한다.
### PATCH - 리소스 부분 변경 1
- PATCH로 변경하고자 하는 부분만 전송(age만 변경 희망, username 필드 없음)
PATCH/members/100 HTTP/1.1
Content-Type: application/json
{
"age":50
}- 서버에 기존 리소스가..
/members/100
{
"username":"young",
"age":20
}### PATCH - 리소스 부분 변경 2
- 변경 희망하는 age만 부분 변경된다.
/members/100
{
"username":"young",
"age":50
}## DELETE
- 리소스 제거
### DELETE - 리소스 제거 1
- DELETE로 members 100번에 대한 제거 요청
DELETE /members/100 HTTP/1.1
Host: localhost:8080- 서버에 있던 기존 리소스가..
/members/100
{
"username":"young",
"age":20
}### DELETE - 리소스 제거 2
- 기존에 서버에 있던 /members 100번 리소스가 제거된다.
### PUT / PATH / DELETE 정리
- PUT : 완전히 대체한다.
- PATCH: 리소스를 부분 변경한다. (간혹 PATCH를 지원하지 않는 경우엔 POST로 진행)
- DELETE : 리소스를 삭제한다.
# HTTP 메서드의 속성
- 안전 (Safe Methods)
- 멱등 (Idenmpotent Methods)
- 캐시가능 (Cacheable Methods)
## 안전 (Safe)
- 호출해도 리소스를 변경하지 않는다.
Q : 그래도 계속 호출해서, 로그 같은게 쌓여 장애가 발생한다면?
A : 안전은 해당 리소스만 고려하므로, 그런 부분은 고려하지 않는다.## 멱등 (Idenmpotent)
- f(f(x)) = f(x)
- 한 번 호출하든, 두 번 호출하든 100번 호출하든 결과는 똑같다.
- 멱등 메서드
GET : 한 번 조회하든, 두 번 조회하든 같은 결과가 조회된다.
PUT : 결과를 대체한다. 따라서 같은 요청을 여러번 해도 최종 결과는 같다.
DELETE : 결과를 삭제한다. 같은 요청을 여러번 해도 삭제된 결과는 똑같다.
* POST : 멱등이 아니다!! 두 번 호출하면 같은 결제가 중복해서 발생할 수 있다.### 멱등의 활용
- 자동 복구 메커니즘
- 서버가 TIMEOUT 등 으로 정상 응답을 못 주었을 때, 클라이언트가 같은 요청을 다시 해도 되는가?의 판단 근거가 된다.
### 멱등 Q : 재요청 중간 다른 곳에서 리소스를 변경해버리면?
사용자 1 : GET 으로 조회 > username : A / age : 20
사용자 2 : PUT 으로 변경 > username : A / age : 30
사용자 1 : GET 으로 조회 > username : A / age : 30
사용자 2의 영향으로 바뀐 데이터가 조회된다.
A : 멱등은 외부 요인으로 중간에 리소스가 변경되는 것 까지는 고려하지 않는다!## 캐시가능 (Cacheable)
- 응답 결과 리소스를 캐시해서 사용해도 되는가?
- GET, HEAD, POST, PATCH 캐시 가능
- 실제로는 GET, HEAD 정도만 캐시로 사용한다.
- POST, PATCH는 본문 내용까지 캐시 키로 고려해야 하는데, 구현이 쉽지 않다.
- 즉, 실무에서는 거의 GET 만 캐시로 사용된다.
출처 : 인프런 모든 개발자를 위한 HTTP 웹 기본 지식
반응형
'인프런 강의 학습 > HTTP 기본 지식' 카테고리의 다른 글
| HTTP 웹 기본 지식 12일차 (0) | 2021.01.12 |
|---|---|
| HTTP 웹 기본 지식 11일차 (0) | 2021.01.12 |
| HTTP 웹 기본 지식 9일차 (0) | 2021.01.02 |
| HTTP 웹 기본 지식 8일차 (0) | 2020.12.31 |
| HTTP 웹 기본 지식 7일차 (0) | 2020.12.30 |