3줄 요약
- Method는 요청 의도를, status code는 처리 결과를, header는 HTTP 계약의 부가 정보를 표현한다.
- GET/PUT/DELETE의 안전성·멱등성과 POST의 중복 처리 위험을 구분해야 retry, idempotency key, 장애 복구를 설계할 수 있다.
- 상태 코드는 결론이 아니라 응답 주체와 다음 확인 계층을 좁히는 운영 단서다.
핵심 정리
- GET은 안전한 조회, PUT/DELETE는 보통 멱등한 변경으로 설계한다. POST는 생성과 명령에 자주 쓰이므로 결제/주문처럼 중복 실행이 치명적인 경우 idempotency key가 필요하다.
- 멱등성은 “응답이 항상 같다”가 아니라 같은 요청을 여러 번 보내도 최종 상태가 추가로 바뀌지 않는다는 뜻이다.
- 2xx, 3xx, 4xx, 5xx는 원인 범위를 1차로 나눈다. 하지만 같은 403/502라도 CDN, WAF, Gateway, App 중 누가 만들었는지에 따라 조치가 달라진다.
- Header는 인증, 캐시, 추적, CORS, forwarding, content negotiation, retry 정보를 담는다. 특히
X-Forwarded-*와 Forwarded는 trusted proxy 경계 없이 믿으면 위험하다.
- API 응답 계약은 status code, error code, message/detail, request id, retry hint, field details까지 포함한다.
- 429/503에는 가능하면
Retry-After를 제공하고, error body에는 운영자가 로그를 찾을 수 있는 request id를 포함한다.
헷갈리는 지점
- 4xx는 모두 사용자 잘못이라고 생각하기 쉽다.
- 핵심 판단 포인트는 WAF, proxy, 인증 설정이 만든 4xx도 있다.
- 5xx는 모두 애플리케이션 버그라고 생각하기 쉽다.
- 핵심 판단 포인트는 Gateway, LB, upstream, timeout이 만든 5xx도 많다.
- POST는 재시도하면 안 된다고만 기억하기 쉽다.
- 핵심 판단 포인트는 idempotency key가 있으면 안전하게 재시도할 수 있는 POST도 설계할 수 있다.
- Header는 서버가 만든 값이라고 생각하기 쉽다.
- 핵심 판단 포인트는 request header는 client가 조작할 수 있고, proxy가 추가/삭제/덮어쓸 수 있다는 것이다.
- 모든 실패를 200
success=false로 보내도 된다고 생각하기 쉽다.
- 핵심 판단 포인트는 monitoring, retry, cache, client 분기가 HTTP 실패를 감지하지 못할 수 있다는 것이다.
확인 질문
- 멱등성이 retry와 연결되는 이유는 무엇인가?
- 같은 요청을 다시 보내도 최종 상태가 중복 변경되지 않아야 안전한 재시도가 가능하기 때문이다.
- 502와 504의 차이는 무엇인가?
- 502는 gateway가 upstream에서 유효한 응답을 받지 못한 것이고, 504는 upstream 응답을 기다리다 timeout이 난 것이다.
- Header를 운영 계약으로 봐야 하는 이유는 무엇인가?
- 인증, 추적, 캐시, CORS, forwarding 정보가 header에 있어 장애 분석과 보안 판단에 직접 쓰이기 때문이다.
- forwarding header를 무조건 신뢰하면 왜 위험한가?
- client가 값을 조작해 IP 기반 rate limit, audit, redirect, 보안 판단을 우회할 수 있기 때문이다.
- 좋은 오류 응답에 request id가 필요한 이유는 무엇인가?
- client가 본 응답과 proxy/application log를 같은 요청으로 연결할 수 있기 때문이다.
- 429/503에
Retry-After를 주는 이유는 무엇인가?
- client가 부하를 더 키우지 않도록 재시도 시점을 알려 주기 위해서다.