HTTP는 요청 메서드를 정의하여, 주어진 리소스에 수행하길 원하는 행동을 나타냅니다. 간혹 요청 메서드를 "HTTP 동사"라고 부르기도 합니다. 각각의 메서드는 서로 다른 의미를 구현하지만, 일부 기능은 메서드 집합 간에 서로 공유하기도 합니다. 이를테면 응답 메서드는 안전하거나, 캐시 가능 하거나, 멱등성을 가질 수 있습니다.
GET 메서드는 특정 리소스의 표시를 요청합니다. GET을 사용하는 요청은 오직 데이터를 받기만 합니다.
HEAD 메서드는 GET 메서드의 요청과 동일한 응답을 요구하지만, 응답 본문을 포함하지 않습니다.
POST 메서드는 특정 리소스에 엔티티를 제출할 때 쓰입니다. 이는 종종 서버의 상태의 변화나 부작용을 일으킵니다.
PUT 메서드는 목적 리소스 모든 현재 표시를 요청 payload로 바꿉니다.
DELETE 메서드는 특정 리소스를 삭제합니다.
CONNECT 메서드는 목적 리소스로 식별되는 서버로의 터널을 맺습니다.
OPTIONS 메서드는 목적 리소스의 통신을 설정하는 데 쓰입니다.
TRACE 메서드는 목적 리소스의 경로를 따라 메시지 loop-back 테스트를 합니다.
PATCH 메서드는 리소스의 부분만을 수정하는 데 쓰입니다.
// 1. 안전(Safe Methods)
// 2. 멱등(Idempotent Methods)
// 3. 캐시가능(Cacheable Methods)
POST, DELETE, PUT, PATCH같이 리소스의 변경을 야기하는 모든 메소드는 안전하지 않다.
HTTP 메소드 중에 GET과 HEAD만 안전하다고 볼 수 있다.
멱등의 성질을 가진 HTTP Method
GET: "한 번 조회하든, 두번 조회하든 조회에 필요한 요청이 같음"
PUT: "결과를 대체한다. 따라서 같은 요청을 여러번 해도 최종 결과는 같다."
DELETE: "결과를 삭제한다. 같은 요청을 여러번 해도 삭제된 결과는 똑같다."
멱등의 성질을 가지지 않은 HTTP Method
POST: "두번 결제하면 중복 결제가 된다."
멱등의 성질
자동 복구 매커니즘
// 만약에 DELETE를 호출했다고 생각해보자,
// 서버가 TIMEOUT등으로 정상 응답을 안주면
// 클라이언트 입장에서 이거 된겨 안된겨?, 삭제 요청 다시 보내도 되나? 할 수 있음
// 이 때 같은 요청을 다시 해도 되는가에 대한 판단 근거가 된다.
GET, HAED, POST, PATCH는 캐시가 스펙상 가능하지만,
실제로는 GET, HEAD 정도만 POST로 사용한다.
왜냐면 캐시를 하려면 키가 맞아야하는데, POST는 body 안에 데이터가 있어 복잡해진다.
GET은 URL만 캐시 하면 되서 GET에서는 자주 쓰인다.