[네트워크] HTTP Method: 멱등성과 안전성, 메서드와 캐싱의 관계

반응형

🌏 HTTP Method

✅ GET

• 서버에서 데이터를 조회(Read)할 때 사용하는 메서드
• 요청 데이터는 주로 쿼리스트링(Query String)으로 전달
• 특징
  • URL에 노출됨 → 북마크 가능, 캐싱 가능
  • 보통 서버 상태를 바꾸지 않음 (멱등성 O)
• 예시
  • GET /users?id=1 → id=1인 사용자 정보 조회

✅ POST

• 서버에 새로운 리소스를 생성(Create)할 때 사용
• 요청 데이터는 Request Body에 담겨 전송
• 특징
  • 캐싱 불가, URL에 보이지 않음
  • 멱등성 X (POST 요청을 여러 번 하면 리소스가 계속 생김)
• 예시
  • POST /users → 새로운 사용자 생성

✅ PUT

• 서버의 리소스를 전체 교체(Update)할 때 사용
• 특징
  • 요청 시 해당 리소스 전체를 덮어씀
  • 멱등성 O (같은 PUT 요청을 여러 번 보내도 결과는 동일)
• 예시
  • PUT/users/1 → id=1인 사용자의 전체 정보를 새로운 데이터로 교체

✅ PATCH

• 서버 리소스의 일부만 수정(Update)할 때 사용
• 특징
  • 부분 변경에 최적화
  • 멱등성은 보장하지 않음 (패치 내용에 따라 다름)
• 예시
  • PATCH /users/1 → id=1인 사용자 이메일만 변경

PUT vs PATCH

• PUT은 리소스를 전체 교체, PATCH는 부분 수정
• REST API 설계 시, 필드 몇 개만 바꾸려는데 PUT을 쓰면 불필요한 데이터까지 전송해야 함.

✅ DELETE

• 서버의 리소스를 삭제(Delete)할 때 사용
• 특징
  • 멱등성 O (여러 번 삭제 요청해도 결과는 동일)
• 예시
  • DELETE /users/1 → id=1인 사용자 삭제

✅ OPTIONS

• 서버가 지원하는 메서드와 CORS 정책을 확인할 때 사용
• 특징
  • 실제 리소스를 가져오지 않고 “사전 요청(Preflight Request)”으로 사용
  • 특히 브라우저에서 CORS 처리 시 자주 등장
• 예시
  • OPTIONS /users → 이 엔드포인트가 GET, POST, DELETE 중 어떤 걸 지원하는지 확인

여기부터는 자주 쓰이지는 않는 Method들입니당

✅ HEAD

• GET과 거의 동일하지만 Response Body는 제외하고 헤더만 응답
• 특징
  • 안전(Safe)하고 멱등(Idempotent)합니다.
  • 트래픽 절약 효과가 있음.
• 활용 예시
  • 리소스가 존재하는지 빠르게 확인할 때
  • Content-Length 헤더를 보고 파일 용량 확인 후 다운로드 여부 결정
  • 캐싱 유효성 확인 (Last-Modified, ETag)

✅ TRACE

• 클라이언트가 보낸 요청을 서버가 그대로 반사(Echo)해서 돌려주는 메서드
• 특징
  • 본래 디버깅용이라 일반 서비스 API에서는 거의 쓰이지 않습니다.
  • 보안상 위험(XSS, 정보 노출 등) 때문에 대부분 서버에서 차단되어 있습니다.
• 네트워크 경로를 따라가며 프록시, 게이트웨이, 방화벽이 요청을 어떻게 변형했는지 디버깅할 때 활용

🌏 멱등성(Idempotency) & 안전성(Safety)

• 안전성(Safe): 서버의 상태를 변경하지 않음 (예: GET, HEAD, OPTIONS)
• 멱등성(Idempotent): 같은 요청을 여러 번 보내도 결과가 변하지 않음 (예: GET, PUT, DELETE)
• 예시
  • POST가 멱등하지 않은 이유: POST는 호출할 때마다 새로운 리소스를 생성하기 때문에 같은 POST 요청을 여러 번 보내면 데이터가 계속 추가되므로 결과가 달라짐
  • DELETE는 멱등한데, 안전하지는 않은 이유: DELETE는 같은 요청을 여러 번 보내도 결과는 동일(리소스가 삭제됨)하므로 멱등성은 있지만 서버의 상태를 바꾸는 동작(리소스 삭제)이므로 안전하지는 않음

🌏 메서드와 캐싱의 관계

CDN(Content Delivery Network)이나 Reverse Proxy 서버(Nginx, Varnish 등)는 클라이언트와 서버 사이에서 응답을 캐싱해주지만, 모든 HTTP Method의 응답을 똑같이 캐싱하지는 않고 메서드별로 다르게 취급합니다.

• GET은 기본적으로 캐싱 가능
  • 이미지, CSS, JS 같은 정적 파일은 CDN이 GET 응답을 캐싱해서 다음 요청 때 빠르게 제공합니다.
  • 브라우저나 프록시는 Cache-Control, Expires, ETag 같은 헤더를 기준으로 캐싱 여부를 결정합니다.
  • cf. HEAD도 GET과 동일하게 캐싱하지만, Response Body는 없으니 헤더 정보만 캐싱
• POST, PUT, DELETE, PATCH는 원칙적으로 캐싱 안함
  • 서버 상태를 바꾸는 성격이 있어 캐싱이 위험하기 때문 (주문이 반복 처리된다던가,,)

 

도움이 되었다면, 공감/댓글을 달아주면 깃짱에게 큰 힘이 됩니다!🌟
비밀댓글과 메일을 통해 오는 개인적인 질문은 받지 않고 있습니다. 꼭 공개댓글로 남겨주세요!