HTTP 메소드

HTTP 메소드

HTTP 메소드에서 주로 사용하는 메소드는 크게 다섯 가지가 존재한다.

• GET : 리소스 조회
• POST : 요청 데이터 처리, 주로 등록에 사용
• PUT : 리소스를 대체, 해당 리소스가 없으면 생성
• PATCH : 리소스 부분 변경
• DELETE : 리소스 삭제

그 외에 기타 메소드들론 다음과 같은 것들이 존재한다.

• HEAD : GET과 동일하지만 메시지 부분이 제외됨,
• OPTION : 대상 리소스에 대한 통신 가능 옵션을 설명
• CONNECT : 대상 리소스로 식별되는 서버에 대한 터널 설정
• TRACE : 대상 리로스에 대한 경로를 따라 메시지 루프백 테스트 수행

HTTP 메소드가 필요한 이유

웹 서비스에서 API URI 를 설계할 때 리소스 식별에 초점을 맞추어 설계해야한다.

리소스에 초점을 맞춘 URI는 다음의 예시와 같다.

• 글 목록 조회 /post
• 특정 글 조회 /post/{pk}
• 특정 글 등록 /post/{pk}
• 특정 글 수정 /post/{pk}
• 특정 글 삭제 /post/{pk}

위의 방식처럼 URI는 행위(ex.post-update-1)이 아닌 오로지 리소스를 식별하는 것만을 목표로 설계하는 것이 바람직하다.

만약 설계가 불가능할 경우 행위를 내포하고 있는 컨트롤 URI를 사용하는 경우도 있다.

근데 문제는 모두 같은 URI 에서 어떻게 다른 API를 구현할까이다.

여기서 HTTP 메소드를 사용해 같은 URI 속에서 다른 API를 제공할 수 있게 된다.

GET,POST

GET

• 리소스 조회
• 서버에 전달하고 싶은 데이터를 query를 통해서 전달
• 바디메시지를 사용할 수 있지만 사용 안 하는 것을 권장(쿼리로 대체)

POST

• 요청 데이터 처리

• 메시지 바디를 통해 서버로 요청 데이터 전달

• 서버는 요청 데이터를 처리

  • GET에서 서버는 그저 요청에 맞는 리소스만을 조회하여 전송하는 기능만 함
  • POST에서는 메시지 바디를 통해 데이터를 받아 조회 외의 다른 데이터 처리 기능까지 수행

• POST로 전달된 데이터를 통해 신규 리소스 등록, 프로레스 처리 등에 사용한다.

PUT, PATCH, DELETE

PUT

• 리소스를 대체
  • 리소스가 있으면 대체
  • 리소스가 없으면 생성
  • 완전한 덮어쓰기
• POST와의 가장 큰 차이는 클라이언트의 리소스 식별 여부이다.
• 수정을 목적으로 사용하는 데 적합하지 않다.

PATCH

• 리소스 부분 변경
• HTML FORM 적용 불가

DELETE

• 리소스 제거
• HTML FORM 적용 불가

HTTP 메소드의 특성

안전

• 호출해도 리소스를 변경하지 않는다.
• 해당 메소드
  • GET
  • HEAD

멱등

• 호출 횟수와 무관하게 결과가 항상 동일해야한다.
• 해당 메소드
  • GET : 수백번 조회해도 결과는 마찬가지
  • PUT : 결과를 덮어쓰기 때문에 동일한 결과
  • DELETE : 삭제된 결과는 항상 동일
• POST는 멱등성에 부합되지 않음
  • 같은 데이터가 중복으로 발생할 수 있음
• 자동 복구 메커니즘등을 위해 주로 사용됨

캐시 가능

• 응답 결과를 리소스를 캐시해서 사용해도 되는가?
• 해당 메소드 :
  • GET
  • HEAD
  • POST, PATCH : 가능은 하지만 본문내용까지 캐시 키로 고려해야 하기 때문에 구현이 쉽지 않아서 거의 사용되지 않음