[API 설계] DELETE request 요청/처리/응답에 관한 소소한 고민

👨🏻‍💻 들어가며

최근 제한된 시간 안에 RESTful API를 설계하고 구현해야 했습니다. 그 와중에 아직 잘 숙지가 되지 않았는지 묘하게 위화감이 있는 부분이 있었는데요, 바로 DELETE 요청 메서드의 처리 정책입니다.

단순히 예제 수준에서 DELETE 요청 메서드로 자원 삭제를 요청하는 것은 정말 쉽지만, 아래 상황에서 고민되는 지점들이 있었습니다.

• DELETE 요청한 클라이언트의 권한을 검사해야하는 상황에서, 인증/인가에 필요한 정보를 어디에 담아서 요청해야할까?
• Soft delete 하는 상황에서 soft delete 여부를 관리하는 컬럼 이름은 무엇이 적절할까?
• 그리고 자원을 삭제하는 것이 아니라 플래그를 바꾸는 것이니 메서드는 PATCH 메서드를 써야하는 걸까?
• DELETE 요청에 대해 응답해야하는 상황에서 어떤 값을 리턴해야할까?

고민한 내용을 DELETE 요청 메서드를 처리하는 과정을 요청, 실행, 응답으로 나눠서 공유합니다.

🔜 요청

보통 RESTful API에서는 동일한 자원에 대해 CRUD 요청을 하더라도, 요청한 클라이언트의 권한에 따라 다르게 동작하도록 구현할 필요가 있습니다. DELETE 요청 메서드는 API 호출 시 자원에 변화를 일으킨다는 점에서 '비안정성'을 가지므로, 권한 검사가 더더욱 필수입니다.

권한 검사는 어떻게 할 수 있을까요? 웹 서비스에서 주로 쓰이는 HTTP 프로토콜은 기본적으로 상태를 저장하지 않으므로(Stateless), DELETE 요청 메세지에 클라이언트를 인증/인가하는데 필요한 정보를 함께 보낼 필요가 있습니다.

그리고 이 정보를 요청 메세지에 담을만한 곳으로 3가지를 고려할 수 있습니다.

URL query string parameter (비추천)

간편하지만 보안상 취약하므로 추천하지 않습니다. 완벽한 보안은 없다지만 "선 넘네..?" 소리가 절로 나올 수 있습니다.

• 인증에 필요한 username, id, password 등 민감 정보가 그대로 노출될 수 있으므로 보안상 좋지 않습니다.
• 또한 아래 이유들 때문에 HTTPS를 사용하더라도 여전히 보안상 좋지 않습니다!
  • server log에 password가 평문으로 그대로 저장될 수 있습니다.
  • 브라우저 히스토리에 URL이 저장될 수 있습니다.
  • Google Analytics 같은 애플리케이션에 Referer 헤더들로 URL이 전달되며 민감정보가 그대로 드러날 수도 있습니다.

Request Body parameter (비추천)

A payload within a DELETE request message has no defined semantics; sending a payload body on a DELETE request might cause some existing implementations to reject the request. - RFC 7231

Request body에 인증/인가 정보를 넣는 것은 어떨까요? URL query string parameter에 비해 URL에 직접 노출이 되지 않으므로 Query string 방식보다는 보안이 좋다고 할 수 있는데요(여전히 암호화는 필수지만), 이례적인 방식이라는 점에서 추천하지 않습니다.

• DELETE 요청시 Request에 body를 포함시키는 것이 금지되어 있지는 않습니다, 하지만 DELETE 요청 메세지에 body가 포함되어있으면 요청을 거절해버리는 서버가 많습니다. 이례적인 방식으로 받아들여지고 있는 것이죠.

별개로 굳이 DELETE 메서드를 고집할 필요가 없다면, Request body에 필요한 정보를 담고, POST 메서드 요청 메세지를 보내는 것도 나쁘지 않은 방법입니다. DELETE 메서드 자체를 허용하지 않는 서버, 방화벽이 많아서 편의성 측면에서 더 좋을 수도 있습니다. 실제로 TOSS의 결제 시스템의 경우, PG 연동 개발자들의 편의를 위해 POST 메서드로 DELETE 요청에 해당하는 API를 디자인한 사례가 있습니다. 관련 내용은 이 링크에 요약해뒀어요 :)

 

Request Header parameter (추천)

Request header에 값을 넣어서 요청하는 것을 추천합니다. Query string보다 보안이 쬐끔이나마 좋고, Body parameter보다 좀 더 일반적인 방법입니다.

제가 확인한 Request header를 이용한 방법 예시는 아래와 같습니다.

• Authorization 헤더에 Bearer 타입을 명시하고, 인증 정보가 담긴 JWT 토큰을 넣어서 보내는 방법
• Authorization 헤더에 Basic 타입을 명시하고, username:password을 BASE64 인코딩해서 HTTPS로 보내는 방법. BASE64는 쉽게 디코딩이 가능하기 때문에 별도 방법으로 암호화할 필요가 있습니다.

🔛 실행

클라이언트의 요청이 유효하다면, 자원을 hard delete 할지, soft delete 할지 선택해야 합니다. 각자 장단점이 있습니다.

Hard delete

• 쿼리를 날릴 때 이전에 'Delete' 처리한 레코드를 신경쓸 필요가 없습니다.
• 데이터베이스 용량이 상대적으로 절약됩니다.
• 한번 삭제하면 데이터를 복구하기 힘듭니다.

Soft delete

• 쿼리를 날릴 때 이전에 'Delete' 처리한 레코드도 신경써줘야 합니다.
• 개인정보와 관련된 레코드를 soft delete 처리한다면 개인정보 보호법을 준수해야 합니다.
• 데이터를 복구하거나 다른 용도로 활용할 때 간편합니다.

Soft delete를 구현할 때 어떤 식으로 구현할지 고민되었는데요, 제 경우 삭제되었는지 여부를 boolean으로 저장하는 column을 추가했습니다. 찾아보니 네이밍은 보통 active/inactive, removed, is_deleted 정도가 고려되는 것으로 보이는데, is_deleted가 가장 취향에 맞았습니다. boolean값 대신 삭제 일시를 datetime으로 저장해서, 해당 컬럼이 null인지 여부를 확인하는 방식으로 관리하는 스타일도 있습니다.

하단은 soft delete시 컬럼 생성에 대한 멘토님의 의견입니다.

아 그리고 이 때 살짝 찜찜할 수도 있는 부분이 있습니다. Soft delete를 할 경우 실제 동작은 자원을 삭제하는 것이 아니라, 컬럼 정보를 일부분 업데이트하는 식으로 작동하니까 PATCH나 PUT 메서드, 혹은 POST 메서드를 활용해야할까요??

확인해보니 이 부분은 이견이 갈리는 것으로 보입니다. 저는 개인적으로 DELETE 메서드를 활용하는 것이 바람직하다고 생각합니다. 요청 메서드에는 클라이언트의 요청 의도가 드러나면 충분하며, 내부 동작은 감춰져 있는 경우가 보통이기 때문입니다.

🔙 응답

A successful response of DELETE requests SHOULD be HTTP response code 200 (OK) if the response includes an entity describing the status, 202 (Accepted) if the action has been queued, or 204 (No Content) if the action has been performed but the response does not include an entity. - RFC 7231

이제 DELETE 메서드를 실행한 결과에 따라 적절한 상태 코드를 응답해주면 됩니다.

• 202(Accepted) : DELETE에 해당하는 요청이 잘 접수되었고, 작업이 실행될 예정일 때.
• 204(No Content) : 작업이 수행되었으며 별도로 내용을 반환할게 없을 때.
• 200(OK) : 작업이 잘 수행되었고, 작업에 대한 내용을 반환할 때.
  ex) 제 경우 프론트엔드를 맡은 동료의 요청에 따라 정상적으로 수행되었을 경우 200 상태코드를 응답하며 삭제된 데이터에 관한 정보를 Body에 넣어서 응답했습니다.

👨🏻‍💻 마치며

API 설계와 구현은 딱 베스트 플렉티스가 있는 것이 아니라 개발 팀의 정책에 따라 선택하는게 맞는 것 같습니다. 그래도 각 방식의 장단점을 고려해서 상황에 맞게 선택할 수 있도록 고민할 기회가 있을 때 미리 고민해두는 것이 좋은 것 같네요 :)

위에서 소개드린 DELETE 메서드 다루는 방식 외에 더 나은 방법이 있다면 댓글로 알려주시면 감사하겠습니다, 성실히 반영하겠습니다!

📕 참고

• API Security - (RESTful) API 구현시 보안처리 방법
• Is an HTTPS query string secure?
• Authorization header
• What is the best way to implement soft deletion
• RESTful Soft Delete
• REST API와 설계원칙
• RFC 7231