HTTP method는 CRUD에 어떻게 대응되며, safe와 idempotent는 무슨 뜻인가?

예시

PUT /users/42는 전체 representation을 보내 교체하고, PATCH /users/42는 바꿀 필드만 보낸다(예: { "email": "[email protected]" }).

safe vs idempotent

이 둘은 서로 다른 속성이다:

• Safe — method가 server 상태를 수정하지 않음(읽기 전용). GET, HEAD, OPTIONS가 safe다.
• Idempotent — 같은 request를 N번 보내도 한 번 보낸 것과 같은 효과. GET, PUT, DELETE, HEAD가 idempotent다.

왜 중요한가

면접관은 당신이 신뢰할 수 있는 API를 만들 만큼 HTTP 시맨틱을 잘 이해하는지 보려고 이를 묻는다. safe/idempotent 구분은 학문적인 것이 아니다: client, proxy, CDN이 무엇을 해도 되는지를 직접 규정한다. safe method는 자유롭게 캐시·prefetch될 수 있고, idempotent method는 네트워크 timeout 후 side effect 중복 위험 없이 자동으로 retry될 수 있다 — 그래서 client는 PUT이나 DELETE를 안전하게 retry할 수 있지만 POST retry는 조심해야 한다(주문 두 개가 생길 수 있다). 고전적 실수는 GET으로 side effect를 유발하는 것(예: GET /users/42/delete)으로, 캐싱을 깨뜨리고 크롤러가 실수로 데이터를 변경하게 만든다. 알맞은 method를 고르고 — 그 safety와 idempotency 계약을 존중하는 것 — 이 API를 예측 가능하고 그 주위에 도구를 만들기 안전하게 한다.