개발자들이 Idempotency에 대해 이해하지 못하는 것

I’m happy to translate the article for you, but I’ll need the full text you’d like translated. Could you please paste the content (excluding the source line you already provided) here? Once I have the article, I’ll keep the source line unchanged and translate the rest into Korean while preserving the original formatting.

빠른 질문

후속 호출에서 404를 반환하는 DELETE 엔드포인트는 멱등성(idempotent)인가요?

응답이 달라졌기 때문에 no라고 답했다면, 이 글이 당신을 위한 것입니다.

멱등성은 경험이 풍부한 개발자들조차도 자주 오해하는 개념입니다.

멱등성은 무엇인가

위키피디아 정의:

멱등성은 수학 및 컴퓨터 과학에서 특정 연산이 처음 적용된 이후 결과를 변경하지 않고 여러 번 적용될 수 있는 특성이다.

In computer science we can phrase it as:

멱등성은 연산이 처음 적용된 이후 결과를 변경하지 않고 여러 번 적용될 수 있는 특성이다.

예시 GET 작업

GET 요청은 일반적으로 데이터베이스를 수정하지 않기 때문에 멱등(idempotent)합니다.
예를 들어:

GET /api/v1/users

몇 번을 호출하든 응답은 동일하며 부작용이 없습니다.

POST, PUT, PATCH 및 DELETE 연산

POST, PUT, PATCH, DELETE에 대한 혼동은 종종 발생합니다.
이들이 멱등성(idempotent)인지 여부는 실제 구현에 따라 결정되며, HTTP 메서드 자체만으로는 판단할 수 없습니다.

POST 연산

사용자를 생성하는 POST 엔드포인트를 예로 들어 보겠습니다.

class User {
    final UUID id;
    final String username;
}

Request

POST /api/v1/users
Content-Type: application/json

{
  "username": "manuelarte"
}

Response (first call)

200 OK
Content-Type: application/json

{
  "id": "f2f7734c-1082-43cf-9b66-9161349ef154",
  "username": "manuelarte"
}

Scenario A – 매번 새로운 사용자가 생성됨

같은 페이로드로 엔드포인트를 다시 호출하면 다른 사용자가 반환됩니다:

200 OK
Content-Type: application/json

{
  "id": "c6fab354-c559-460b-a66c-5d0bad8f6aba",
  "username": "manuelarte"
}

각 요청이 새로운 리소스를 생성하므로 엔드포인트는 멱등하지 않음입니다.

Scenario B – 첫 호출과 동일한 응답

두 번째 호출이 첫 번째 호출과 같은 사용자를 반환한다면:

200 OK
Content-Type: application/json

{
  "id": "f2f7734c-1082-43cf-9b66-9161349ef154",
  "username": "manuelarte"
}

시스템 상태가 첫 번째 요청 이후 변하지 않으므로 엔드포인트는 멱등합니다.

Scenario C – 다른 응답 코드이지만 상태 변화 없음

두 번째 호출이 사용자가 이미 존재한다는 오류를 반환한다고 가정해 보겠습니다:

400 Bad Request
Content-Type: application/json

{
  "code": "USER_CREATED",
  "message": "user already created"
}

HTTP 상태 코드가 다르더라도 기본 상태(단일 사용자)는 변하지 않으므로 엔드포인트는 여전히 멱등합니다.
멱등성은 최종 상태에 관한 것이며, 응답 코드와는 무관합니다.

DELETE 엔드포인트

일반적인 DELETE 요청은 응답 코드와 관계없이 멱등합니다:

DELETE /api/v1/users/{id}

• 첫 번째 호출은 리소스를 삭제 → 204 No Content.
• 이후 호출은 리소스가 없음을 확인 → 404 Not Found (또는 204 No Content).

첫 번째 성공적인 삭제 이후의 상태가 이후 모든 호출에서 동일하기 때문에, 엔드포인트는 멱등합니다.

비멱등 Delete 예시

DELETE /api/v1/users/last

각 호출이 현재 마지막 사용자를 삭제한다면(예: 첫 번째 호출은 사용자 5를, 두 번째 호출은 사용자 4를 삭제) 요청마다 상태가 변하므로 엔드포인트는 멱등하지 않음입니다.

Summary and takeaways

• Idempotency means that consecutive calls with the same data do not change the system’s state after the first successful request.
• It is about state, not about HTTP methods or response codes.
• Understanding this helps with:
  • API design – building services that can safely retry requests.
  • Client implementation – handling varying response codes correctly.
  • Contract testing – writing accurate tests for API behavior.

Next time you design or consume an API, remember:

• Idempotency = State doesn’t change after the first request
• HTTP methods suggest idempotency, but the implementation guarantees it.

For more details see RFC 9110 and resources on implementing idempotency with headers.