[UMC_study] Soft Delete 란?

Soft Delete 란?

 

Soft Delete(소프트 삭제)는 데이터를 데이터베이스에서 실제로 영구적으로 지우는 대신, 삭제된 것처럼 표시하는 디자인 패턴입니다. 

 

사용자는 데이터가 삭제된 것으로 보지만, 실제 데이터는 데이터베이스에 그대로 남아있어 언제든지 복구할 수 있다는 장점이 있습니다.

 

보통 is_deleted, deleted_at과 같은 특정 칼럼(플래그)을 두어 데이터의 삭제 여부를 구분합니다.

 

예를 들어, deleted_at 칼럼에 삭제된 시점의 타임스탬프가 기록되어 있다면, 애플리케이션에서는 이 데이터가 삭제된 것으로 간주하고 사용자에게 보여주지 않습니다.

 

 

Soft Delete에 적합한 HTTP Method

Soft Delete를 구현할 때 어떤 HTTP Method를 사용해야 하는지에 대해서는 여러 의견이 있지만, 가장 널리 쓰이고 의미적으로 적합한 두 가지 방법은 다음과 같습니다.

1. PATCH

가장 권장되는 방법 중 하나입니다. PATCH는 리소스의 일부만 수정할 때 사용하는 메소드입니다. Soft Delete는 데이터 전체를 삭제하는 것이 아니라 is_deleted나 deleted_at과 같은 특정 상태 값만 변경하는 것이므로, PATCH의 의미와 정확히 일치합니다.

 

요청 예시:

HTTP

 

PATCH /users/123
Content-Type: application/json

{
  "is_deleted": true
}

 

2. DELETE

 

전통적으로 리소스 삭제에 사용되는 DELETE 메소드를 그대로 사용하는 경우도 많습니다. 이 방법은 API를 사용하는 입장에서 직관적이라는 큰 장점이 있습니다. '삭제' 행위를 나타내기 위해 DELETE 메소드를 호출하는 것은 매우 자연스럽습니다.

• 장점: API의 의도가 명확하고 이해하기 쉽습니다.
• 단점: DELETE는 원래 리소스를 완전히 제거하는 것을 의미하므로, Soft Delete의 '상태 변경'이라는 실제 동작과는 약간의 의미적 차이가 있을 수 있습니다.
• 요청 예시:서버는 이 요청을 받으면 내부적으로 해당 사용자의 상태를 '삭제됨'으로 변경합니다.
• HTTP

   

  DELETE /users/123
  

---

결론: 어떤 것을 선택해야 할까?

Method	장점	단점
PATCH	리소스의 일부를 수정한다는 의미에 정확히 부합함.	'삭제'라는 행위에 대해 PATCH를 사용하는 것이 직관적이지 않을 수 있음.
DELETE	API 사용이 매우 직관적이고 명확함.	리소스를 완전히 제거한다는 DELETE의 원래 의미와는 다소 차이가 있음.

 

결론적으로, 두 방법 모두 널리 사용되며 틀렸다고 할 수 없습니다.

• RESTful API의 의미론적 정확성을 더 중요하게 생각한다면 PATCH가 더 나은 선택입니다.
• API의 직관성과 사용 편의성을 우선시한다면 DELETE를 사용하는 것이 더 효과적일 수 있습니다.

팀의 컨벤션이나 프로젝트의 특성에 따라 더 적합한 방식을 선택하는 것이 좋습니다.