본문 바로가기
CS/네트워크

[네트워크] HTTP Methods 차이점 정리

by eess 2024. 8. 6.

 

 

HTTP 메서드

  • HTTP 프로토콜에서 사용되는 요청 메서드로, 자원에 대해 서버가 수행할 동작을 지정합니다.
  • 총 9가지가 있으며 REST API를 설계할 때 주로 사용되는 메서드는 5가지입니다.

 

주요 메서드 5가지

  • GET : 서버로부터 자원을 요청하는 동작
  • POST : 서버로 데이터를 전송하여 자원을 생성하거나 업데이트 하는 동작
  • PUT : 서버에 자원을 생성하거나 기존 자원을 대체하는 동작
  • PATCH : 서버 자원의 일부만 수정하는 동작
  • DELETE : 서버에서 자원을 삭제하는 동작

 

GET vs POST

1. GET

  • 목적
    • 서버로부터 자원을 요청하는 동작
  • 데이터 전송 방식
    • 요청 본문을 사용하지 않고, 요청 URI에 Path Variable 이나 Query String 을 사용할 것을 권장합니다.
  • 보안
    • 데이터가 URL에 포함되므로 URL이 서버 측 접속 로그나 브라우저 히스토리에 저장될 수 있습니다. 이로 인해 민감 데이터가 노출될 가능성이 있습니다.
    • 해결 방법
      • POST 요청 본문에 데이터 담기
      • HTTPS로 요청하여 전송 구간 암호화하기(BUT 로그나 브라우저 히스토리에 남는 문제는 해결되지 않음!)
      • 애초에 민감한 정보(사용자 인증 토큰, 개인 정보, 비밀번호 등)가 URL Query String에 들어가지 않도록 설계하기
      • 클라이언트에서 Query String 암호화 후 GET 요청 -> 서버에서 복호화 후 데이터 처리
  • 데이터 길이 제한 O
    • 웹 브라우저와 서버마다 다르지만 URL의 길이 제한이 있습니다.
  1. 캐싱 O
    1. GET 요청의 응답은 캐싱 가능합니다.
    2. 웹 브라우저가 서버로부터 받은 GET 요청의 응답을 로컬 캐시에 저장하고, 동일 요청이 있을 때 서버에 다시 요청하지 않고 캐시에 저장된 응답을 사용할 수 있습니다.
  2. 멱등성 O
    1. 멱등성이 보장됩니다. 즉, 동일 요청을 한 번 보내는 것과 여러 번 연속 보내는 것이 같은 효과를 지닙니다.

 

2. POST

  • 목적
    • 서버로 데이터를 전송하여 자원을 생성하거나 업데이트 하는 동작
  • 데이터 전송 방식
    • 요청 본문(body)에 데이터를 포함합니다.
  • 보안
    • 데이터가 URL에 포함되지 않으므로 GET 요청에 비해 상대적으로 안전합니다.
    • 그래도 데이터 암호화 하려면 HTTPS 를 써야 합니다. (e.g. Nginx client_max_body_size 등)
  • 데이터 길이 제한 O
    • POST 요청 본문의 데이터 길이 제한은 GET 보다는 상대적으로 크지만, 절대적으로 길이 제한이 없는 것은 아닙니다.
    • 웹 서버나 서버 애플리케이션 측에서 요청 본문 크기에 대한 설정을 해줄 수 있습니다.
    • (참고) 서버를 뻗게 하는 원인이 될 수 있으므로 대용량 데이터 처리는 별도로 분리하는 게 좋다고 합니다. [참고1] [참고2]
  • 캐싱 X
    • POST 요청의 응답은 기본적으로 캐시되지 않습니다. [참고 - RFC 7231]
      • 멱등성이 보장되지 않기 때문입니다.
      • POST 요청 본문에는 민감 데이터가 포함될 수 있으므로 캐싱하면 보안 위험이 있습니다.
      • 대용량 데이터가 전송될 수 있기 때문에 캐싱이 메모리 성능에 이점을 주지 않습니다.
  • 멱등성 X
    • 멱등성이 보장되지 않습니다. 즉, 동일 요청을 한 번 보내는 것과 여러 번 연속 보내는 것이 다른 효과를 지닐 수 있습니다.

 

3. GET vs POST 차이점 정리

  GET POST
목적 자원 요청 자원 생성 / 업데이트
데이터 전송 방식 URI Query String / Path Variable 요청 본문
보안 URL에 민감 데이터가 드러날 수 있음 URL에 민감 데이터가 드러나지 않아 GET 보다는 상대적으로 안전함
데이터 길이 제한 ✅ ✅
캐싱 ✅ ❌
멱등성 ✅ ❌

 

PUT vs PATCH vs DELETE

1. PUT

  • 목적
    • 서버에 자원을 생성하거나 기존 자원을 대체하는 동작
  • 데이터 전송 방식
    • 지정된 URI의 자원을 수정합니다.(Path Variable)
    • 요청 본문에 자원의 전체 데이터를 포함하여 전송합니다.
  • 보안
    • 자원 전체에 대한 권한 검증이 필요합니다.
  • 캐싱 X
    • PUT 요청의 응답은 기본적으로 캐싱되지 않습니다.
  • 멱등성 O
    • PUT 요청은 멱등성을 보장합니다. 동일한 요청을 여러 번 보내도 결과는 동일합니다.

 

2. PATCH

  • 목적
    • 서버 자원의 일부만 수정하는 동작
  • 데이터 전송 방식
    • 지정된 URI의 자원을 수정합니다.(Path Variable)
    • 요청 본문에는 수정할 데이터의 일부만 포함합니다.
  • 보안
    • 자원 전체, 수정할 필드에 대한 권한 검증이 필요합니다. 
  • 캐싱 X
    • PATCH 요청의 응답은 기본적으로 캐싱되지 않습니다.
  • 멱등성 X
    • PATCH 요청은 멱등성을 보장하지 않습니다. 
    • 하지만 PUT과 같은 방식으로 사용한다면(자원 전체 대체) 멱등성을 가지게 할 수도 있습니다.

3. DELETE

  • 목적
    • 서버에서 자원을 삭제하는 동작
  • 데이터 전송 방식
    • 지정된 URI의 자원을 수정합니다.(Path Variable)
    • 요청 본문은 필요하지 않습니다.
  • 보안
    • 자원에 대한 권한 검증이 필요합니다.
  • 캐싱 X
    • DELETE 요청의 응답은 기본적으로 캐싱되지 않습니다.
  • 멱등성 O
    • DELETE 요청은 멱등성을 보장합니다. 자원이 삭제되면 여러 번 요청을 보내도 결과는 같습니다.

 

4. PUT vs PATCH vs DELETE 차이점 정리

  PUT PATCH DELETE
목적 자원 생성 / 전체 대체 자원 일부 수정 자원 삭제
데이터 전송 방식 URI Path Variable, 요청 본문 URI Path Variable, 요청 본문 URI Path Variable
보안 권한 검증 필요 권한 검증 필요 권한 검증 필요
캐싱 ❌ ❌ ❌
멱등성 ✅ ❌ ✅

 

5. POST vs PUT 차이점 정리

  POST PUT
목적 자원 생성 / 업데이트 자원 생성 / 전체 대체
데이터 전송 방식 요청 본문 URI Path Variable, 요청 본문
멱등성 ❌ ✅

 

  • POST과 PUT 요청 둘 다 자원을 생성할 수도, 업데이트 할 수도 있습니다. 
  • 가장 큰 차이점은 멱등성 보장 여부라고 볼 수 있는데요. 
    • POST는 멱등성을 보장하지 않습니다. 서버가 자원의 URI를 결정하기 때문에 POST는 자원을 생성할 때 사용하는 게 좋고, 자원 일부 업데이트에는 의미상 PATCH가 좀 더 적합할 수 있습니다.
    • PUT은 멱등성을 보장합니다. 자원의 URI를 포함해서 요청을 보낼 수 있고, 자원 전체 업데이트의 경우 PUT이 더 적합하다고 볼 수 있겠습니다.

 

나머지 메서드 4가지

  • HEAD
    • GET과 동일하지만, 응답 본문을 포함하지 않습니다. 서버는 요청된 자원의 헤더만 반환합니다.
    • 자원을 다운로드하지 않고 자원의 메타데이터나 존재 여부를 점검하는 데 사용할 수 있습니다. 
    • 또한 클라이언트가 캐싱을 사용하는 경우 HEAD 요청을 통해 응답의 Last-Modified 헤더나 ETag 헤더를 검사해 로컬에 캐시된 버전이 최신인지 확인할 수 있습니다. [참고]
  • CONNECT
    • 클라이언트와 서버 간의 터널 설정 동작
    • 클라이언트가 HTTPS 요청을 프록시 서버를 통해 목적지 서버로 보내려할 때 CONNECT 메서드를 사용하여 프록시 서버와 터널을 설정합니다. 프록시 서버는 이 요청을 받아서 목적지 서버와의 TCP 연결을 설정하고, 이 연결을 클라이언트와 프록시 서버 사이에 터널링합니다.
  • OPTIONS
    • 서버에서 지원하는 메서드 옵션을 요청하는 동작
    • 서버가 특정 자원에 대해 어떤 HTTP 메서드를 지원하는지 확인할 수 있습니다.
    • 또한, CORS(Cross-Origin Resource Sharing) 정책을 확인하는 데에도 사용됩니다. 클라이언트(= 웹 브라우저)가 다른 도메인의 자원에 접근하려고 할 때, Preflight 요청으로 OPTIONS 요청을 보내 서버가 허용하는 메서드와 헤더를 확인합니다. [참고]
  • TRACE
    • 요청을 따라 경로 추적하여 최종 웹 서버로 가는 네트워크 경로를 체크하는 동작
    • TRACE 메서드를 사용해 XST(Cross-Site Tracing) 공격을 할 수 있으므로, 서버에서는 TRACE 메서드를 허용하지 않도록 설정합니다. [참고]
    • 따라서 주로 네트워크 문제 진단을 위해 디버깅 용도로 사용됩니다.

 

참고

 

저작자표시 비영리 변경금지

티스토리툴바