네트워크
HTTP 메서드와 안전한 재시도
메서드의 안전성(Safe), 멱등성(Idempotency), 그리고 전송 기밀성은 서로 다른 성질이며 재시도 설계의 기준이 됩니다.
이럴 때 필요해요
네트워크가 일시적으로 끊겼을 때 어떤 요청은 자동으로 다시 보내도 괜찮고, 어떤 요청은 중복 결제나 중복 생성을 일으킬 수 있는지 구분하기 위해 필요합니다.
어떻게 동작하나요?
사용자가 화면을 조회할 때 쓰는 GET은 서버의 자원 상태를 바꾸지 않는 안전(Safe)한 메서드이고, 프로필 전체를 주어진 값으로 교체하는 PUT이나 삭제하는 DELETE는 같은 요청을 여러 번 보내도 최종 자원 상태가 한 번 보낸 것과 같게 유지되는 멱등(Idempotent) 메서드입니다. 반면 주문 생성이나 댓글 등록 등에 쓰는 POST는 서버가 요청 본문을 받아 새로운 처리를 수행하게 하므로 기본적으로 멱등성이 보장되지 않습니다.
자원의 일부분만 수정하는 PATCH는 안에 담긴 명령에 따라 멱등성이 달라집니다. 예를 들어 '닉네임을 진으로 설정'하는 PATCH는 여러 번 적용해도 결과가 같지만, '보유 포인트를 100점 차감'하거나 '목록 끝에 항목 추가'하는 PATCH는 반복 호출할 때마다 상태가 계속 바뀝니다. 또한 여러 사람이 같은 문서를 동시에 고칠 때는 ETag와 If-Match 헤더로 버전이 맞을 때만 수정하게 하여 남의 수정본을 덮어쓰는 사고를 막습니다.
여기서 주의할 점은 '멱등성'이 매번 똑같은 HTTP 상태 코드를 받는다는 뜻이 아니라 '서버 자원에 미치는 의도된 상태 효과가 같다'는 뜻이라는 점입니다(예: 첫 DELETE는 200, 재시도 DELETE는 404일 수 있음). 또한 POST 본문에 데이터를 넣는다고 해서 자동으로 암호화되는 것은 아니므로 기밀성은 반드시 HTTPS(TLS)로 챙겨야 하며, 결제처럼 민감한 비멱등 요청을 재시도할 때는 별도의 멱등성 키(Idempotency-Key) 계약을 서버와 함께 맞추어야 합니다.
코드 예제
동작을 설명하는 읽기 전용 예제입니다.
PUT /profiles/7 HTTP/1.1
Host: example.test
If-Match: "version-4"
Content-Type: application/json
{"displayName":"Jin"}조건부 갱신 요청의 예시입니다. 클라이언트가 알고 있는 버전("version-4")과 서버의 현재 ETag가 다르면 서버는 412 Precondition Failed를 반환해 다른 사용자의 수정을 덮어쓰지 않도록 막을 수 있습니다.
자주 헷갈리는 포인트
- POST 요청은 데이터가 URL이 아니라 본문(Body)에 들어가므로 HTTPS 없이도 암호화되어 안전하다고 오해하면 안 됩니다.
- HTTP 명세상 멱등 메서드(GET, PUT)라도 백엔드 서버가 명세를 어기고 호출마다 부수 효과를 일으키게 구현했다면 안전한 재시도가 깨질 수 있습니다.
내 말로 설명해 보기
네트워크 타임아웃으로 응답을 받지 못한 '조회수 1 증가' PATCH 요청을 그대로 자동 재시도해도 괜찮을까요? 중복 반영을 막으려면 어떤 계약이 필요할까요?
실전 시나리오에 적용해 보기
함께 읽으면 좋은 개념
관련 면접 질문 2개
HTTP에서 GET과 POST는 의미, 캐싱, 보안 측면에서 어떻게 다른가요?
GET은 서버 자원의 표현을 조회하는 안전(Safe)하고 멱등(Idempotent)한 메서드이고, POST는 서버가 요청 본문을 받아 생성이나 상태 변경 등을 처리하게 하는 비멱등 메서드입니다. GET은 기본 캐싱이 자연스럽지만 POST는 명시적 캐시 조건이 있어야 캐시할 수 있습니다. 또한 두 메서드 모두 자체 암호화를 제공하지 않으므로, 민감 정보는 URL 노출을 피해 본문으로 보내되 반드시 HTTPS(TLS)와 로그 마스킹 정책을 함께 적용해야 합니다.
꼬리질문과 참고자료 →HTTP의 PUT과 PATCH는 자원 갱신 의미와 멱등성(Idempotency)에서 어떤 차이가 있나요?
PUT은 대상 자원의 상태를 요청한 표현으로 생성하거나 완전히 교체하는 의미여서 여러 번 보내도 결과 상태가 같은 멱등(Idempotent) 메서드입니다. 반면 PATCH는 부분 변경 명령을 적용하므로, 단순 값 대입이면 멱등할 수 있지만 '카운터 1 증가' 같은 연산이면 호출할 때마다 결과가 달라져 비멱등일 수 있습니다. 동시 수정 환경에서는 ETag와 If-Match 조건부 요청을 함께 사용해 다른 사용자의 변경을 덮어쓰는 충돌을 예방합니다.
꼬리질문과 참고자료 →