2021.12.29

✔️ PUT

PUT /members/100 HTTP/1.1
Content-Type: application/json

{
    "username":"hello",
    "age":20
}

리소스가 이미 있다면 대체되고 없으면 새로 생성한다. 다시 말해서 복붙을 생각하면 되는데, 리소스를 덮어버리는 역할을 한다고 보면 된다.

• POST와의 차이점은 클라이언트가 리소스의 구체적인 전체 경로를 알고 있어 URI를 지정함으로써 리소스를 식별한다.

✔️ PATCH

PATCH /members/100 HTTP/1.1
Content-Type: application/json

{ 
    "age":10
}

리소스의 부분을 변경할 수 있다. 위의 예시를 보자면, /members/100의 기존 username 필드 필요없이 변경 사항만 서버로 전달해주면 username 값은 유지된 채 age의 값만 변경된다.
가끔 PATCH를 지원하지 않는 서버가 있을 경우, POST를 사용하면 된다.

✔️ DELETE

DELETE /members/100 HTTP/1.1
Host: localhost:8080

리소스를 제거하는 역할을 한다.

---

HTTP 메서드 속성

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

1. 안전

호출해도 리소스를 변경하지 않는다는 뜻이다. 조회만 하는 GET과 HEAD는 안전하다 볼 수 있다.

• 계속 호출해서 로그가 쌓여 장애가 발생하면? 안전은 리소스의 변경 유무만 판단할 뿐, 다른 부분은 고려하지 않는다!

2. 멱등

f(f(x)) = f(x)
한 번이나 두 번이상 호출하든 결과가 항상 같다.
멱등 메서드

• GET : 여러번 조회해도 같은 결과가 조회된다.
• PUT : 결과를 대체한다. 따라서 같은 요청을 여러번 해도 최종 결과는 같다.
• DELETE : 결과를 삭제하므로 같은 요청을 여러번 보내도 삭제된 결과는 같다.
• <주의> POST : 멱등이 아니다!! 두 번 호출하면 같은 결제가 중복해서 발생할 수 있기 때문이다.

활용

• 자동 복구 매커니즘 : 똑같은 요청을 여러번 해도 상관없음
• 서버가 TIMEOUT되어서 정상 응답을 주지 못했을 때 클라이언트가 같은 요청을 해도 되나? ㅇㅇ
• 재요청 중간에 다른 곳에서 리소스를 변경할 경우는?
  User1 : GET -> username:A, age:20
  User2 : PUT -> username:A, age:30
  User1 : GET -> username:A, age:30 => User2의 영향으로 바뀐 데이터 조회
  멱등은 외부 요인으로 중간에 리소스가 변경되는 것 까지 고려하지 않는다!

3. 캐시 가능

• 응답 결과 리소스를 캐시해서 사용해도 되는가?
• GET, HEAD, POST, PATCH 캐시 가능하지만 실제로는 GET, HEAD 정도만 캐시로 사용된다. POST, PATCH는 본문 내용까지 캐시 키로 고려해야 되는데 구현하기 복잡하다.