HTTP Method

개념

• 클라이언트와 서버 사이 이뤄지는 요청(Request)과 응답(Response) 데이터를 전송하는 방식

• 서버가 수행해야할 동작을 지정하는 요청을 보내는 방법

사용 이유

• 리소스와 동작을 분리하기위해 사용

  • HTTP Method : 서버가 수행해야할 동작 지정

  • URL : 리소스만 식별

종류

주요 메소드

• GET : 리소스 조회

• POST : 요청 데이터 처리, 등록

• PUT : 리소스 대체(덮어쓰기), 해당 리소스가 없을 시 생성

• PATCH : 리소스 부분 번경

• DELETE : 리소스 삭제

기타 메소드

• HEAD : 리소스 조회 (body부분을 제외한 상태줄과 헤더 만 반환)

• OPTIONS : 대상 리소스에 대한 통신 가능 옵션을 설명 (주로 CORS에서 사용)

• CONNECT : 대상 자원으로 식별되는 서버에 대한 터널 설정

• TRACE : 대상 리소스에 대한 경로를 따라 메시지 루프백 테스트 수행

HTTP Method의 속성

✔️ 안전

• URL을 호출해도 리소스가 변하지 않는 것

• 해당 메서드

  • GET, HEAD, OPTIONS, TRACE

• 사용자의 요청에 의한 리소스만 고려하며 구현에 따른 부작용은 고려하지 않음

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

✔️ 멱등

• 여러 번 동일한 요청을 보냈을 때, 서버에 미치는 의도된 영향이 동일한 경우

• 해당 메서드

  • GET, HEAD, ,PUT, DELETE, OPTIONS, TRACE

• 멱등은 외부요인으로 리소스가 변형되는 것까지 고려하지 않음

  • EX) PUT/DELETE와 같이 리소스의 변형을 준 연산 전후 진행 된 GET

• 멱등성이 필요한 경우

  • 요청의 재시도

    • HTTP요청이 멱등시, 요청 실패할 경우 재시도 요청 가능

    • HTTP요청이 멱등하지 않을 시, 이미 처리된 리소스에 중복 요청을 보낼 수 있음

    • 이처럼 멱등성을 고려해 재시도의 요청을 진행함

• 사용자의 요청에 의한 리소스만 고려하며 구현에 따른 부작용은 고려하지 않음

✔️ 캐시 가능

• 메서드 응답결과 리소스를 캐시로 사용할 수 있는지에 대한 판단

• 해당 메서드

  • GET, HEAD

    • 실제로는 GET, HEAD 정도만 사용

  • POST, PATCH

    • 복잡성 발생: BODY안의 데이터까지 고려해야 함

주요 메소드

GET

리소스 조회 메서드 (READ)

• 멱등성을 가짐

  • 이때, 재요청 중간에 리소스가 변경되는것은 고려하지 않음

• 캐싱이용으로 조회속도가 빠름

데이터 조회

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

정적 데이터 조회

• 특징

  • 이미지, 정적 텍스트 문서

  • 쿼리 파라미터 없이 리소스 경로로 단순 조회 가능

• 과정

  1. 클라이언트의 GET요청

  2. GET /members/100 HTTP/1.1

  3. 서버는 요청 메세지 분석 → 정보 조회 → Response 생성

  4. 서버에서 클라이언트로의 응답

동적 데이터 조회

• 특징

  • 주로 검색으로 이용

  • 쿼리 파라미터를 사용해 데이터 전달

    • 쿼리 파라미터

      • 구조: key1=value1&key2=value2

      • ? : 리소스 경로 뒤에 ? 문자를 붙여 시작

      • & : 추가적인 데이터 이어줌

    • URL에 데이터가 그대로 노출되기때문에 보안에 취약

• 동작

  1. 요청 URL뒤에 쿼리 파라미터 줌

  2. 상세한 조회 데이터 얻음

HTML FORM 데이터 조회

• 특징

  • HTML Form 태그 문서로 사용자와 UI로 상호작용하여 서버와 통신

  • HTML Form 전송은 GET, POST만 지원

• 동작

  1. 웹 문서 폼 입력칸에 데이터를 적고 전송 버튼 클릭

  2. 지정한 GET메서드 동작에 따라 input태그 안의 값들이 쿼리스트링으로 서버로 전송

데이터 전달

• 쿼리 파라미터을 통해 서버에 전달하고 싶은 데이터 전달

  • 전달하는 데이터의 정보가 무방비로 노출됨

• 메시지 바디를 이용할 수도 있으나 권장하지 않음

  • 서버에서 따로 구성해야하기 때문

POST

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

• 전달된 데이터로 주로 신규 리소스 등록, 프로세스 처리에 사용

  • 새로운 데이터를 계속 생성하므로 요청 시 마다 데이터 생성

• 메시지 바디(body)를 통해 서버로 요청 데이터 전달하면 서버는 요청 데이터를 처리하여 업데이트

• 데이터를 GET 하는데 있어, JSON으로 조회 데이터를 넘겨야 하는 애매한 경우 POST를 사용

• 멱등성을 지니지 않아 POST매서드 여러번 수행 시, 같은 결과값을 보장하지 않음

데이터 전달

• 메세지 Body에 쿼리 파라미터 형식으로 데이터 전달

  • 쿼리 파라미터는 Key-Value 형식으로 구성됨

  • 메세지 길이의 제한이 없음

• GET과 달리 데이터가 외부로 노출되지 않음

• 문자열 데이터와 더불어 객체 값 또한 전송 가능

  • EX) Radio Button

PUT

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

• 요청 메세지에 리소스가 있으면 덮어쓰고, 없으면 새로 생성

• 클라이언트가 리소스 식별 가능

  • 클라이언트가 구체적인 리소스 위치를 아는 상태에서 URL 지정

  • 데이터를 대체하므로 클라이언트는 리소스의 구체적인 전체 경로를 지정해야함

  • 클라이언트가 데이터를 지정, 수정하기에 반복되는 같은 요청에 데이터가 계속 생성되지 않음

• 멱등성을 지님

PATCH

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

• PATCH를 지원하지 않는 서버에서는 POST를 대신 사용

• 멱등성을 지니지 않음

  • 보다 정확히 말하면, 리소스의 특정 부분 변경 방식이 멱등이게도 멱등이지 않게도 설정 가능

  • 멱등 O: 기존의 값과 상관없이 어떤 데이터를 변경

  • 멱등 X: 기존의 값에 어떤 연산을 진행한 결과를 바탕으로 데이터 변경

DELETE

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

• 상태코드는 대부분 200 사용, 상황에 따라 204 사용

• 멱등성을 지님

  • 멱등성의 기준이 상태코드가 아님

    • DELETE후 받은 응답코드가 달라도 멱등함

  • 서버에 미치는 의도된 영향이 동일함

    • DELETE의 목적: 리소스를 삭제하여 서버에 리소스가 없도록 만드는 것

    • DELETE 여러번 호출 후: 응답 상태와 무관하게 리소스가 없는 상태를 유지

  • 여러번의 요청에도 리소스가 동일하므로 멱등함 (리소스의 관점에서 생각)

기타 메소드

HEAD

• GET과 동일하나 서버에서 Body를 Return하지 않음

• 일종의 검사 용도

  • Resource를 받지 않고 오직 찾기만 원할 때 사용

  • EX) 응답의 상태 코드만 확인할 경우

• 서버의 응답 헤더를 봄으로써 Resource가 수정되었는지 확인 가능

TRACE

• 일종의 검사용 매소드

• 서버에 도달 했을 때의 최종 패킷의 요청 패킷 내용을 응답 받을 수 있음

• 요청의 최종 수신자는 반드시 송신자에게 200(OK) 응답의 내용(Body)으로 수신한 메세지를 반송해야함

• 최초 클라이언트의 요청에는 Body가 포함될 수 없음

• 요청, 응답했던 패킷 내용을 비교하여 변조 유무 확인 가능

  • 클라이언트의 요청 패킷이 방화벽, Proxy 서버, Gateway 등을 거치면서 패킷의 변조가 일어날 수 있음

OPTION

• 예비 요청(Preflight)에 사용되는 HTTP메소드

  • 예비 요청(Preflight) : 본 요청 진행 전 안전한지 미리 검사하는 것

• CORS 정책을 검사하기 위한 요청

  • 서버의 지원 가능한 HTTP메서드와 출처를 응답받음

Ref

HTTP 메서드 종류 & 요청 흐름 💯 총정리 [WEB] HTTP Method란? [HTTP] HTTP 메소드의 멱등성(Idempotence)과 Delete 메소드가 멱등한 이유