존재하지 않는 리소스의 DELETE 요청에 대한, 상태값은 204와 404 중 무엇이 적절할까요?

[sangjun121]

RFC 7231 스펙 문서에 따르면, DELETE 메서드는 기본적으로 명등성한 메서드입니다.

만약 id가 없는 리소스에 대해 DELETE 메서드를 호출했다면 204와 404 중 무엇을 제공해주는 것이 적절할까요?

참고리소스 - HTTP 메소드의 멱등성(Idempotence)과 Delete 메소드가 멱등한 이유

[softmoca]

구분 짓고 가야할 부분

저는 이 주제에서 먼저 구분해야 하는 지점은
“DELETE의 멱등성”과 “응답 상태 코드가 항상 같아야 하는가”는
다른 문제라는 점이라고 생각합니다.

DELETE가 멱등하다는 것은 같은 요청을 여러 번 보내도 서버의 최종 상태가 같아야 한다는 의미이지,
매번 같은 응답 코드를 반환해야 한다는 의미는 아니라고 이해했습니다.

예를 들어 /reservations/1 리소스를 삭제하는 요청을 보냈다고 가정해보면,

• DELETE /reservations/1
  첫 번째 요청에서는 리소스가 존재하므로 삭제가 수행됩니다.
• 204 No Content

이후 같은 요청을 다시 보내면 이미 리소스는 존재하지 않습니다.
하지만 서버 상태는 여전히 “해당 리소스가 없음”입니다.

즉, 첫 번째 요청 이후에도 없고, 두 번째 요청 이후에도 없습니다.
따라서 응답 코드가 204 → 404로 달라져도 멱등성이 깨진 것은 아니라고 생각합니다.

무엇이 더 적절한지에 대한 해석

그렇다면 204와 404 중 무엇이 더 적절한지는,
API가 DELETE 요청을 어떻게 해석하느냐에 따라 달라질 수 있다고 봅니다.

1. “삭제 결과”에 초점을 두면 204도 가능하다

클라이언트의 의도가 “이 리소스가 더 이상 존재하지 않게 해줘”라면,
이미 존재하지 않는 상태도 목표 상태를 만족한 것으로 볼 수 있습니다.

이 관점에서는 존재하지 않는 리소스에 DELETE를 보내도 최종 상태가 원하는 대로 되었으므로,
204 No Content를 반환할 수 있다고 생각합니다.

특히 클라이언트가 재시도 로직을 가지고 있는 경우에는 204가 더 단순할 수 있습니다.

• 삭제 요청 → 네트워크 오류 → 재시도

이때 첫 번째 요청은 서버에서 성공했지만 응답만 유실되었을 수 있습니다.
재시도 시점에는 이미 리소스가 없으므로 404가 내려올 수 있는데,
클라이언트 입장에서는 이것을 실패로 봐야 할지 애매해질 수 있습니다.

그래서 “삭제 이후 리소스가 없어지면 성공”이라는 계약이라면 204가 자연스러울 수 있습니다.

2. “삭제 대상의 존재 여부”에 초점을 두면 404도 가능하다

반대로 DELETE 요청을 “존재하는 특정 리소스를 삭제해줘”라는 의미로 해석한다면,
해당 id의 리소스가 애초에 없다는 사실은 클라이언트에게 알려줄 만한 정보입니다.

이 관점에서는 삭제할 대상이 없으므로 404 Not Found가 더 명확할 수 있습니다.

• DELETE /reservations/999
• 404 Not Found

특히 사용자가 잘못된 id를 요청했거나,
프론트엔드가 이미 사라진 리소스를 참조하고 있는 상황이라면
404가 디버깅과 사용자 피드백에 더 도움이 될 수 있습니다.

그래서 저는 정답이 하나로 고정된다기보다,
API 계약을 어떻게 잡을 것인가의 문제라고 생각합니다.

저의 기준

제 기준으로는 이렇게 구분할 수 있을 것 같습니다.

관점	적절한 상태 코드	이유
“없어지게 하는 것”이 목표	204	이미 없으므로 목표 상태 달성
“존재하는 리소스를 삭제”하는 것이 목표	404	삭제할 대상이 없음을 명확히 알림

다만 일반적인 CRUD API라면 저는 404 Not Found 쪽이 조금 더 명확하다고 생각합니다.

이유는 DELETE 요청의 대상이 URI로 식별되는 특정 리소스이고,
그 리소스가 존재하지 않는다면 “요청한 리소스를 찾을 수 없다”는
사실을 클라이언트에게 알려주는 것이 자연스럽기 때문입니다.

• DELETE /reservations/{id}

여기서 {id}가 잘못되었거나 이미 삭제된 리소스라면,
클라이언트가 그 사실을 아는 것이 이후 흐름에 도움이 될 수 있다고 봅니다.

최종 정리

결론적으로 저는 이렇게 정리할 수 있을 것 같습니다.

DELETE의 멱등성은 “같은 요청을 반복해도 서버의 최종 상태가 같아야 한다”는 의미이지,
“항상 같은 응답 코드를 반환해야 한다”는 의미는 아니다.

따라서 존재하지 않는 리소스에 대한 DELETE 응답은 204와 404 모두 설계 의도에 따라 가능하다고 생각합니다.

다만 현재 API가 일반적인 리소스 중심 CRUD에 가깝고,
클라이언트에게 “해당 리소스가 존재하지 않는다”는 정보를 명확히 전달하고 싶다면,
404 Not Found를 선택할 것 같습니다.

[sangjun121]

한줄 정리

DELETE가 멱등한지를 결정 짓는 요인이 상태 코드가 아니기 때문에, 서비스 요구사항에 맞게 204와 404를 함께 사용하는 것이 적절하다입니다!

204: 리소스를 성공적으로 삭제하였을 때 받게 되는 응답 상태 코드
404: 이미 삭제된 리소스를 delete하는 재요청이나, 실존하지 않는 리소스를 삭제하는 경우 받게 되는 응답 상태코드

이렇게 2가지로 나눠 관리해야 클라이언트 입장에서 예외를 처리하기 용이할 것 같습니다.

DELETE의 멱등성은 언제 준수되는가?

A request method is considered "idempotent" if the intended effect on the server of multiple identical requests with that method is the same as the effect for a single such request.

RFC 공식 문서에 따르면 멱등성의 정의는 "여러번 동일한 요청을 보냈을 때, 서버에 미치는 의도된 영향이 동일한 경우"를 의미합니다. 즉, 멱등성은 사용자 요청에 의한 리소스만을 고려하고 구현에 따른 부작용은 고려하지 않습니다.(여기서 구현에 따른 부작용은 예를 들어 존재하지 않는 id로 요청하여 리소스를 찾는데 실패한 상황을 예로 들 수 있을 것 같습니다.)

또한 외부 용인에 의해 변경된 사항 또한 멱등성의 고려 대상이 아닙니다.(예를 들면, 다른 트랜잭션이 중간에 끼워들어 연속적인 GET 요청의 응답이 다른 경우가 될 수 있을 것 같습니다.)

결국, 멱등하냐를 따질때는 상태 코드가 아닌 서버의 리소스를 관점으로 판단해야 한다고 생각합니다.
따라서, 204이든 404이든, DELETE를 여러 번 호출해도 응답 상태와 무관하게 리소스가 없는 상태를 유지한다면, 멱등하다고 말할 수 있습니다.

제 생각

결국, 상태코드는 멱등한지에 영향을 주지 않기 때문에, 204와 404를 함께 사용해도 괜찮다라는 것이 저의 생각입니다. 따라서 404 NOT FOUND 상태코드를 제공해줌으로서, 프론트에서 예외 처리를 하기 더 용이하게 직관적으로 전달하고, 디버깅에 용이하도록 설계하는 것이 더 실용적이라고 생각합니다.

[haeyoon1]

만약 id가 없는 리소스에 대해 DELETE 메서드를 호출했다면 204와 404 중 무엇을 제공해주는 것이 적절할까요?

단순히 삭제 요청이 잘 처리되었음을 표시하기위해서는 204 응답을 주어도 괜찮습니다.

DELETE가 멱등한 메서드인 이유는 리소스가 있을 때에도, 없을 때에도 모두 리소스가 없는 결과를 유지하기 때문입니다.
멱등성 측면으로 판단하였을 때는, 기존에 데이터의 유무(==과정)에 상관없이 해당 요청의 결과를 가지고 판단하면 되기에 204 응답을 반환하는 것 또한 틀린 선택은 아닌 것 같습니다.

하지만 사용자 친화적인 방법을 고려해보았을 때는 404를 제공해주는 것이 더욱 적절하다 생각됩니다!

사용자 입장에서 특정 데이터를 삭제한다고 하였을 때
없는 데이터를 삭제했을 때에도 정상적으로 삭제되었다는 204 응답을 주게된다면, 잘못된 데이터를 지운건 아닌지 혼란이 올 수 있을 것 같아요.
혹은 A 데이터를 삭제하려 하였으나 실수로 존재하지 않는 B 데이터를 삭제하는 요청을 보냈을 때에도, 404 응답을 반환해준다면 실수를 인지할 수 있지만 정상 응답이 반환되면 직접 데이터를 확인하지 않는 이상 불가능합니다.

대부분의 경우에 보내는 요청이 정상적인 요청인지 검증하는 로직은 있는 것이 안전하다 생각됩니다.
그렇기에 삭제 요청에도 검증 로직이 들어가게되면 자연스럽게 404응답을 반환할 것 같네요!

[koreaioi]

멱등성 - 서버의 리소스 상태가 동일한가?

• 204, 404든 삭제되었다는 리소스 상태는 동일
• 즉, API 요청마다 상태코드가 달라도 멱등성 여부와는 무관하다.
• 따라서 같은 요청에 대해 상태코드가 달라지는 건 고려하지 X

---

RESTful API는 결과보다 자원(resource)을 우선으로 바라보는 설계라고 생각합니다.
때문에, 일반적인 상황에서 404가 더 적절하다고 생각합니다.

대부분 떠오르는 케이스는 다음과 같습니다.

1. 첫번째 DELETE /times/{id}로 등록된 시간을 삭제함.
2. 두번째 DELETE /times/{id}로 삭제된 시간을 다시 삭제하려함.
   이때, 두번째 경우를 204로 할 것이냐, 404로 할 것이냐를 고민 할 것입니다.

여기서 "첫번째 단계에서부터 존재하지 않는 id로 요청을 보내도 204를 보낼 것이냐" 를 생각해보았습니다. 이 경우 404를 반환해야 한다고 생각합니다.

DELETE 요청은 "삭제된 상태를 만들어달라는 게" 아니라, "URL이 가리키는 특정 Resource를 삭제해달라는 요청" 이기 때문입니다. 따라서, 자원이 우선이며, 해당 자원이 존재하지 않는다면 대상을 찾을 수 없다는 의미의 404가 더 자연스럽다고 생각합니다.

[haeyoon1]

이 질문에 대한 생각이 바뀌었는데요, 저는 204(혹은 200 + 빈 body)를 반환할 것 같습니다.

처음에는 리소스가 없으니 404가 더 적절하다고 생각했는데, 운영 관점에서 404는 두 가지 의미를 가질 수 있습니다.

• 잘못된 URL로 요청한 경우: 컨트롤러에 도달하지 못한 라우팅 실패
• URL은 정상적이지만 해당 id에 해당하는 도메인 데이터가 없는 경우

그런데 이 둘은 성격이 다르다고 생각합니다.
라우팅 실패는 장애에 가까운 상황이지만, 도메인 데이터가 없는 것은 단순히 해당 시점에 삭제할 대상이 없는 정상적인 상황일 수 있기 때문입니다.

현업에서는 API Gateway가 업스트림의 404 응답을 라우팅 실패로 해석해 Circuit Breaker를 발동시키는 경우도 있다고 들었습니다. 모니터링 관점에서도 라우팅 실패와 비즈니스 데이터 없음은 중요도가 다르기 때문에, 이를 같은 404로 표현하면 원인 파악이나 알림 기준이 애매해질 수 있을 것 같습니다.

그래서 DELETE 요청의 경우, 리소스가 실제로 존재해서 삭제되었든 이미 존재하지 않았든 결과적으로 리소스가 없는 상태가 되었다면 요청은 성공한 것으로 보고 204를 반환하는 것이 적합할 것 같아요!

또한 존재하지 않는 id에 대한 삭제 요청은 클라이언트의 잘못된 요청이라기보다 멱등한 삭제 요청의 결과로 볼 수 있으므로, 해당 이유에서도 204가 더 적합해보입니다!

[sangjun121]

좋은 인사이트 공유 감사합니다.

현업에서는 API Gateway가 업스트림의 404 응답을 라우팅 실패로 해석해 Circuit Breaker를 발동시키는 경우도 있다고 들었습니다.

이 부분에 대해 학습해봐도 좋을 것 같네용