HTTP 메서드

1. API 설계 시
2. HTTP 메서드의 종류
3. HTTP 메서드의 속성

API 설계 시

URI에서 중요한 것은 리소스 식별, 리소스만 식별하면 된다.
행위(조회, 등록, 삭제, 수정 등)는 HTTP 메서드로 분리

HTTP 메서드의 종류

1. GET : 리소스 조회
   서버에 전달하고 싶은 데이터는 query(쿼리 파라미터, 쿼리 스트링)를 통해서 전달, 메시지 바디도 사용 가능하지만, 지원하지 않는 곳이 많다. 권장 X

2. POST : 요청 데이터 처리, 주로 등록에 사용
   메시지 바디를 통해 서버로 요청 데이터 전달
   POST는 새 리소스를 생성 및 등록, 요청 데이터 처리(프로세스의 상태가 변경되는 경우), 다른 메서드로 처리하기 애매한 경우에 사용한다.
   POST 메서드는 대부분의 요청을 처리할 수 있지만, 캐싱을 이용하기 힘들기 때문에 조회하는 경우 GET을 쓰도록 한다.

3. PUT : 리소스를 완전히 대체, 해당 리소스가 없으면 생성
   클라이언트가 리소스를 식별 (POST와는 다르게 클라이언트가 리소스의 위치를 알고 URI를 지정)
   ex) PUT /members/100 HTTP/1.1
   ex) POST /members HTTP/1.1
   리소를 완전히 대체하기 때문에 부분 수정이 불가능하다.

4. PATCH : 리소스 부분 변경
   PATCH를 지원하지 않으면 POST를 대신 사용한다.

5. DELETE : 리소스 삭제

HTTP 메서드의 속성

1. 안전 (Safe Methods)
   호출해도 리소스를 변경하지 않는다. 해당 리소스에 대해서만 생각함

2. 멱등 (Idempotent Methods)
   같은 요청을 여러 번 호출해도 결과가 똑같다.
   외부 요인으로 중간에 리소스가 변경되는 것 까지는 고려하지 않는다.

   GET, PUT, DELETE는 멱등하다.
   PUT, DELETE도 똑같은 요청을 보냈을 때, 대체 또는 삭제의 결과가 항상 같기 때문이다.
   하지만 POST는 멱등하지 않다. 같은 요청이 들어왔을 때, 중복해서 프로세스가 실행될 수 있기 때문이다. (POST를 통해 결제 요청이 두번 들어오면 중복하여 결제될 수 있음)

   멱등한 요청은 자동복구 메커니즘에 사용할 수 있다. 패킷이 손실되거나, TIMEOUT이 발생했을 때, 같은 요청을 다시 보내도 문제가 되지 않는다.

3. 캐시가능 (Cacheable Methods)
   GET, HEAD, POST, PATCH는 캐시가 가능하다.
   하지만 POST, PUT은 본문 내용까지 캐시 키로 고려해야 하는데, 구현이 쉽지 않기 때문에 실제로는 GET, HEAD 정도만 캐시로 사용한다.

해당 포스팅은 김영한님의 인프런 강의 "모든 개발자를 위한 HTTP 웹 기본 지식"를 수강하고 배운 내용을 정리한 글입니다.