(스프링부트 Rest API) 다건 삭제 관련

Bulk delete

 

일반적으로 HTTP 메소드를 사용할 때 데이터 위치는 아래와 같습니다.

GET, DELETE => header에 데이터 포함
POST, PUT => body에 데이터 포함

 

방법 1

첫 번째 방법은 구분자를 사용해서 path로 데이터를 넘기는 방법입니다.

• DELETE /resources/1;2;3;4
• DELETE /resources/1+2+3+4
• DELETE /resources/1,2,3,4

 

방법 2

두 번째 방법은 QueryString을 사용하는 방법입니다.

• DELETE /resources?id=1&id=2&id=3&id=4

 

방법 3

세 번째 방법은 POST나 PUT을 사용하는 방법입니다. 

 

첫 번째, 두 번째 방법의 문제점은 길이의 제약이 있다는 점입니다. 브라우저마다 URL의 Maximum length가 다르지만 보통 2048자나 2083자입니다.

 

이는 문제가 생길 가능성이 있습니다. 예를 들어, 클라이언트가 해당 길이 이상의 Id array를 URL에 담고 보내려 하면 당연히 문제가 발생하겠죠.

 

그래서 POST나 PUT을 사용해서 Body를 사용할 수 있게 설계할 수 있습니다.

• POST /resources/batch-delete 
• POST /resources/deleteList

이 경우 Body를 { ids: [] } 형태로 전송할 수 있습니다.

 

방법 4

네 번째 방법은 그냥 DELETE에 Body를 사용하는 것입니다.

 

ElasticSearch의 RestAPI의 경우에는 지금도 일부는 GET과 DELETE에서 Body를 사용합니다.

 

하지만 이는 좋은 방법이 아닙니다.

 

RFC2616 (HTTP 1.1)은 이렇게 설명합니다.

• Entity-Body 전송을 하지 않는 경우 Message-Body에 포함하지 말아라!

즉, "서버는 Entity 본문을 정의하지 않으므로, Message-Body를 무시하라" 라는 의미를 가집니다.

 

따라서 Entity id는 본문에 있어선 안되고, Entity Body가 아닌 것이 Message Body에 있어선 안됩니다.

 

• Android 에서는 DELETE와 함께 본문을 전송할 수 없음
• Tomcat, Weblogic은 Payload가 있는 DELETE 요청을 거부
• OpenAPI 사양에서 본문이 있는 DELETE 요청 지원을 중단
• Google Cloud HTTPS LoadBalancer가 상태 값 400을 반환하는 DELETE 요청을 거부
• Sahi Pro는 DELETE 요청에 제공된 Body를 무시
• 일부 버전의 Tomcat 및 Jetty는 엔터티 본문을 무시

 

결론

 

API 스펙이 원래 모호하고 정답이 없는 부분이라고 생각하지만,

 

개인적으로 REST API 스펙으로는 첫 번째에 언급되었던 DELETE /resources/1,2,3,4 방법이 가장 REST에 가깝고 깔끔하게 처리할 수 있지 않나 생각합니다.

 

물론 다른 방법도 비즈니스 로직, 타협점에 따라 사용할 수도 있을 것 같습니다.

 

감사합니다.

 

 

참고:

- https://stackoverflow.com/questions/299628/is-an-entity-body-allowed-for-an-http-delete-request

- https://peterdaugaardrasmussen.com/2020/11/14/rest-should-you-use-a-body-for-your-http-delete-requests/

- https://jaehoney.tistory.com/147

REST/HTTP - Should you use a body for your DELETE requests?