HTTP method는 리소스에 대한 당신의 의도를 나타내고; status code는 서버의 코드화된 답이다. method에는 두 속성이 중요하다: safe(읽기 전용, side effect 없음)와 idempotent(반복해도 같은 결과 — 안전한 retry에 중요).
| Method | 목적 | Safe | Idempotent |
|---|
| GET | 리소스 읽기 | Yes | Yes |
| POST | 생성 / 액션 트리거 | No | No |
| PUT | 리소스 교체 | No | Yes |
| PATCH | 부분 업데이트 | No | No* |
| DELETE | 리소스 제거 | No | Yes |
| HEAD | GET과 같으나 header만 | Yes | Yes |
idempotency 구분은 실용적이다: PUT과 DELETE는 idempotent이므로 클라이언트가 timeout 후 안전하게 retry할 수 있다; idempotent이 아닌 POST를 retry하면 중복 생성 위험이 있다(고전적인 이중 청구 버그).
Status code는 첫 자릿수로 묶인다:
1xx Informational request received, continuing (100 Continue, 101 Switching)
2xx Success it worked (200 OK, 201 Created, 204 No Content)
3xx Redirection go elsewhere (301 Moved, 304 Not Modified)
4xx Client error YOUR request is wrong (400, 401, 403, 404, 429)
5xx Server error the SERVER failed (500, 502, 503, 504)
가장 중요한 경계선은 4xx vs 5xx 구분이다: 4xx는 클라이언트가 잘못 보냈다는 뜻이고(잘못된 입력, 미인증, 찾을 수 없음) — 그대로 retry해도 소용없다; 5xx는 서버가 실패했다는 뜻이며 — retry(backoff와 함께)하면 성공할 수 있다. 일상적인 것들을 확실히 알아두라: 401(미인증) vs 403(인증됐지만 허용 안 됨), 404(찾을 수 없음), 429(rate limit), 500(일반적 서버 크래시), 502/503/504(bad gateway / 사용 불가 / gateway timeout — 보통 upstream이나 과부하 문제).
이 코드들은 모든 클라이언트와 서버 사이의 공통 계약이므로, 여기에 능숙한 것은 API를 만들거나 사용하는 누구에게나 기대된다. 면접관은 진짜 이해를 드러내는 구분을 살핀다: 401 vs 403, PUT vs PATCH, 그리고 특히 idempotency — retry가 안전한지를 직접 좌우하는 것으로, 분산 시스템과 결제 흐름에서 핵심 관심사다. 올바른 status code를 반환하는 것은 또한 당신의 API를 예측 가능하게 만들고 cache, proxy, 클라이언트 라이브러리가 올바르게 처리하게 하므로, 이 지식은 단순한 잡지식이 아니라 좋은 API 설계를 빚어낸다.
주니어부터 시니어까지 상세한 답변이 포함된 IT 면접 질문 라이브러리.
후원하기