# HTTP Method

### 개념

* 클라이언트와 서버 사이 이뤄지는 `요청(Request)`과 `응답(Response)` 데이터를 전송하는 방식
* 서버가 수행해야할 동작을 지정하는 요청을 보내는 방법

<br>

### 사용 이유

* 리소스와 동작을 분리하기위해 사용
  * `HTTP Method` : 서버가 수행해야할 동작 지정
  * `URL` : 리소스만 식별

<br>

### 종류

**주요 메소드**

* `GET` : 리소스 조회
* `POST` : 요청 데이터 처리, 등록
* `PUT` : 리소스 대체(덮어쓰기), 해당 리소스가 없을 시 생성
* `PATCH` : 리소스 부분 번경
* `DELETE` : 리소스 삭제

<br>

**기타 메소드**

* `HEAD` : 리소스 조회 (body부분을 제외한 상태줄과 헤더 만 반환)
* `OPTIONS` : 대상 리소스에 대한 통신 가능 옵션을 설명 (주로 CORS에서 사용)
* `CONNECT` : 대상 자원으로 식별되는 서버에 대한 터널 설정
* `TRACE` : 대상 리소스에 대한 경로를 따라 메시지 루프백 테스트 수행

\
\ <br>

## HTTP Method의 속성

### ✔️ 안전

* URL을 호출해도 리소스가 변하지 않는 것
* 해당 메서드
  * `GET`, `HEAD`, `OPTIONS`, `TRACE`
* 사용자의 요청에 의한 리소스만 고려하며 구현에 따른 부작용은 고려하지 않음

> 여기서의 안전은 서버 장애와 관련된 부분이 아닌 리소스의 변형유무를 뜻함

<br>

### ✔️ 멱등

* 여러 번 동일한 요청을 보냈을 때, 서버에 미치는 의도된 영향이 동일한 경우
* 해당 메서드
  * `GET`, `HEAD`, ,`PUT`, `DELETE`, `OPTIONS`, `TRACE`
* 멱등은 외부요인으로 리소스가 변형되는 것까지 고려하지 않음
  * EX) PUT/DELETE와 같이 리소스의 변형을 준 연산 전후 진행 된 GET
* 멱등성이 필요한 경우
  * `요청의 재시도`
    * HTTP요청이 멱등시, 요청 실패할 경우 재시도 요청 가능
    * HTTP요청이 멱등하지 않을 시, 이미 처리된 리소스에 중복 요청을 보낼 수 있음
    * 이처럼 멱등성을 고려해 재시도의 요청을 진행함
* 사용자의 요청에 의한 리소스만 고려하며 구현에 따른 부작용은 고려하지 않음

<br>

### ✔️ 캐시 가능

* 메서드 응답결과 리소스를 캐시로 사용할 수 있는지에 대한 판단
* 해당 메서드
  * `GET`, `HEAD`
    * 실제로는 GET, HEAD 정도만 사용
  * `POST`, `PATCH`
    * 복잡성 발생: BODY안의 데이터까지 고려해야 함

\
\ <br>

`주요 메소드`

## GET

> 리소스 조회 메서드 (READ)

<br>

* `멱등성`을 가짐
  * 이때, 재요청 중간에 리소스가 변경되는것은 고려하지 않음
* `캐싱`이용으로 조회속도가 빠름

<br>

### 데이터 조회

* GET메서드는 캐싱이 가능하므로 POST보다 유리

<br>

**정적 데이터 조회**

* 특징
  * 이미지, 정적 텍스트 문서
  * 쿼리 파라미터 없이 리소스 경로로 단순 조회 가능
* 과정
  1. 클라이언트의 GET요청
  2. `GET /members/100 HTTP/1.1`
  3. 서버는 요청 메세지 분석 → 정보 조회 → Response 생성
  4. 서버에서 클라이언트로의 응답

<br>

**동적 데이터 조회**

* 특징
  * 주로 검색으로 이용
  * 쿼리 파라미터를 사용해 데이터 전달
    * `쿼리 파라미터`
      * 구조: `key1=value1&key2=value2`
      * `?` : 리소스 경로 뒤에 ? 문자를 붙여 시작
      * `&` : 추가적인 데이터 이어줌
    * URL에 데이터가 그대로 노출되기때문에 보안에 취약
* 동작
  1. 요청 URL뒤에 쿼리 파라미터 줌
  2. 상세한 조회 데이터 얻음

<br>

**HTML FORM 데이터 조회**

* 특징
  * HTML Form 태그 문서로 사용자와 UI로 상호작용하여 서버와 통신
  * HTML Form 전송은 GET, POST만 지원
* 동작
  1. 웹 문서 폼 입력칸에 데이터를 적고 전송 버튼 클릭
  2. 지정한 GET메서드 동작에 따라 input태그 안의 값들이 쿼리스트링으로 서버로 전송

<br>

### 데이터 전달

* `쿼리 파라미터`을 통해 서버에 전달하고 싶은 데이터 전달
  * 전달하는 데이터의 정보가 무방비로 노출됨
* `메시지 바디`를 이용할 수도 있으나 권장하지 않음
  * 서버에서 따로 구성해야하기 때문

\ <br>

## POST

> 전달한 데이터 처리/생성 요청 메서드 (Create)

<br>

* 전달된 데이터로 주로 신규 리소스 등록, 프로세스 처리에 사용
  * 새로운 데이터를 계속 생성하므로 요청 시 마다 데이터 생성
* 메시지 바디(body)를 통해 서버로 요청 데이터 전달하면 서버는 요청 데이터를 처리하여 업데이트
* 데이터를 GET 하는데 있어, JSON으로 조회 데이터를 넘겨야 하는 애매한 경우 POST를 사용
* `멱등성`을 지니지 않아 POST매서드 여러번 수행 시, 같은 결과값을 보장하지 않음

<br>

### 데이터 전달

* 메세지 Body에 `쿼리 파라미터` 형식으로 데이터 전달
  * 쿼리 파라미터는 Key-Value 형식으로 구성됨
  * 메세지 길이의 제한이 없음
* GET과 달리 데이터가 외부로 노출되지 않음
* 문자열 데이터와 더불어 객체 값 또한 전송 가능
  * EX) Radio Button

\ <br>

## PUT

> 리소스를 **완전히** 대체(수정)하는 메서드 (Update)

<br>

* 요청 메세지에 리소스가 있으면 덮어쓰고, 없으면 새로 생성
* 클라이언트가 리소스 식별 가능
  * 클라이언트가 구체적인 리소스 위치를 아는 상태에서 URL 지정
  * 데이터를 대체하므로 클라이언트는 리소스의 구체적인 전체 경로를 지정해야함
  * 클라이언트가 데이터를 지정, 수정하기에 반복되는 같은 요청에 데이터가 계속 생성되지 않음
* `멱등성`을 지님

\ <br>

## PATCH

> 리소스 **일부 부분**을 변경하는 메소드 (Update)

<br>

* PATCH를 지원하지 않는 서버에서는 POST를 대신 사용
* `멱등성`을 지니지 않음
  * 보다 정확히 말하면, 리소스의 **특정 부분 변경 방식**이 멱등이게도 멱등이지 않게도 설정 가능
  * 멱등 O: 기존의 값과 상관없이 어떤 데이터를 변경
  * 멱등 X: 기존의 값에 어떤 연산을 진행한 결과를 바탕으로 데이터 변경

\ <br>

## DELETE

> 리소스를 제거하는 메소드 (Delete)

<br>

* 상태코드는 대부분 200 사용, 상황에 따라 204 사용
* `멱등성`을 지님
  * 멱등성의 기준이 상태코드가 아님
    * DELETE후 받은 응답코드가 달라도 멱등함
  * 서버에 미치는 의도된 영향이 동일함
    * DELETE의 목적: 리소스를 삭제하여 서버에 리소스가 없도록 만드는 것
    * DELETE 여러번 호출 후: 응답 상태와 무관하게 리소스가 없는 상태를 유지
  * 여러번의 요청에도 리소스가 동일하므로 멱등함 (리소스의 관점에서 생각)

\ <br>

`기타 메소드`

## HEAD

* GET과 동일하나 서버에서 Body를 Return하지 않음
* 일종의 검사 용도
  * Resource를 받지 않고 오직 찾기만 원할 때 사용
  * EX) 응답의 상태 코드만 확인할 경우
* 서버의 응답 헤더를 봄으로써 Resource가 수정되었는지 확인 가능

\ <br>

## TRACE

* 일종의 검사용 매소드
* 서버에 도달 했을 때의 최종 패킷의 요청 패킷 내용을 응답 받을 수 있음
* 요청의 최종 수신자는 반드시 송신자에게 200(OK) 응답의 내용(Body)으로 수신한 메세지를 반송해야함
* 최초 클라이언트의 요청에는 Body가 포함될 수 없음
* 요청, 응답했던 패킷 내용을 비교하여 변조 유무 확인 가능
  * 클라이언트의 요청 패킷이 방화벽, Proxy 서버, Gateway 등을 거치면서 패킷의 변조가 일어날 수 있음

\ <br>

## OPTION

* 예비 요청(Preflight)에 사용되는 HTTP메소드
  * `예비 요청(Preflight)` : 본 요청 진행 전 안전한지 미리 검사하는 것
* [CORS 정책](https://jmxx219.gitbook.io/cs/sop#corscross-origin-resource-sharing)을 검사하기 위한 요청
  * 서버의 지원 가능한 HTTP메서드와 출처를 응답받음

\ <br>

### Ref

[HTTP 메서드 종류 & 요청 흐름 💯 총정리](https://inpa.tistory.com/entry/WEB-%F0%9F%8C%90-HTTP-%EB%A9%94%EC%84%9C%EB%93%9C-%EC%A2%85%EB%A5%98-%ED%86%B5%EC%8B%A0-%EA%B3%BC%EC%A0%95-%F0%9F%92%AF-%EC%B4%9D%EC%A0%95%EB%A6%AC)\
[\[WEB\] HTTP Method란?](https://youwjune.tistory.com/42)\
[\[HTTP\] HTTP 메소드의 멱등성(Idempotence)과 Delete 메소드가 멱등한 이유](https://mangkyu.tistory.com/251)
