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

 

 

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 메서드를 허용하지 않도록 설정합니다. [참고]
  • 따라서 주로 네트워크 문제 진단을 위해 디버깅 용도로 사용됩니다.

 

참고

• 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
• https://developer.mozilla.org/en-US/docs/Web/HTTP/Methods
• https://okky.kr/questions/437467
• https://2jinishappy.tistory.com/314
• https://okky.kr/questions/307144
• https://medium.com/@shiny.shubham/caching-post-requests-a8401c1e2e41
• https://www.inflearn.com/community/questions/1182007/patch%EC%99%80-put%EC%9D%98-%EC%B0%A8%EC%9D%B4%EC%A0%90