[HTTP]HTTP 메서드

API URI를 설계함에 있어서 가장 중요한 것은 리소스 식별이다.

 

여기서 리소스에 대해서 간략하게 알아보자면 회원을 등록/수정/조회/삭제하는 API를 개발할 때 등록/수정/조회/삭제를 하는 주체가 되는 회원이 리소스이다.

 

이러한 리소스를 이용해 URI를 설계를 하게 되면 리소스를 URI에 매핑을 해주고 리소스와 해당 리소스를 대상으로 하는 행위를 분리시킨다.

• 리소스 : 회원
• 행위 : 등록, 수정, 조회, 삭제 등등

이제부터는 리소스를 이용한 HTTP 메서드 종류들을 알아보도록 하자

 

GET

• 리소스를 조회
• 서버에 전달하고자 하는 데이터는 query(쿼리 파라미터, 쿼리 스트링)를 통해서 전달
• 메시지 바디를 사용해서 데이터를 전달할 수 있지만, 지원하지 않는 곳이 많기에 권장하진 않는다.

 

POST

• 요청 데이터를 처리
• 메시지 바디를 통해서 서버로 요청 데이터 전달
• 서버는 요청 데이터를 처리
  • 메시지 바디를 통해 들어온 데이터를 처리하는 모든 기능을 수행한다.
• 주로 전달된 데이터로 신규 리소스 등록, 프로세스 처리에 사용
• 리소스 URI에 POST 요청이 오면 요청 데이터를 어떻게 처리할지 리소스마다 따로 정해야 된다. -> 정해진 것이 따로 없기 때문이다.

 

PUT

• 리소스를 대체 
  • 리소스가 있으면 대체
  • 리소스가 없으면 생성
• 클라이언트가 리소스를 식별
  • 클라이언트가 리소스 위치를 알고 URI 지정
  • POST와의 차이 -> POST는 서버가 리소스를 생성한다.

 

PATCH

• 리소스를 변경시킨다.

 

DELETE

• 리소스를 제거한다.

 

HTTP 메서드의 속성

안전

• 호출해도 리소스를 변경하지 않는다.

 

멱등

• 한 번 호출하든 두 번 호출하든 몇 번을 호출하든 결과는 같다.
• 멱등 메서드
  • GET : 몇 번을 조회하든 같은 데이터가 조회된다.
  • PUT : 결과를 대체한다. 리소스가 없으면 리소스를 생성하고 리소스가 있으면 리소스를 대체한다. -> 결국 리소스가 있든 없든 결과는 같다.
  • DELETE : 결과를 삭제한다. 한 번을 요청하든 두 번을 요청하든 삭제하는 결과는 같다.
• 활용
  • 자동 복구 메커니즘
  • 서버가 정상 응답을 주지 못 했을 때 -> 클라이언트가 같은 요청을 다시 해도 되는지의 판단 근거가 된다.

 

캐시가능

• GET, HEAD, POST, PATCH 캐시가능 -> 실제로는 GET, HEAD 정도만 캐시로 사용, POST/PATCH는 본문 내용까지 캐시 키로 고려해야 되는데 구현이 쉽지가 않다.

 

이렇게 주로 사용되는 HTTP 메서드를 알아봤는데 이 외에 HEAD, OPTIONS, CONNECT, TRACE 등도 있는데 간단하게 알아보자

• HEAD : GET과 동일하지만 메시지 부분을 제외하고, 상태 줄과 헤더만 반환
• OPTIONS : 대상 리소스에 대한 통신 가능 옵션을 주로 설명
• CONNECT : 대상 자원으로 식별되는 서버에 대한 터널을 설정
• TRACE : 대상 리소스에 대한 경로를 따라 메시지 루프백 테스트를 실행

 

---

출처 : 인프런 우아한 형제들 최연소 기술이사 김영한의 스프링 완전 정복(모든 개발자를 위한 HTTP 웹 기본 지식)