REST를 사용하여 여러 레코드 삭제
여러 항목을 삭제하는 REST-ful 방법은 무엇입니까?
내 사용 사례는 한 번에 여러 항목을 삭제할 수 있어야하는 백본 컬렉션이 있다는 것입니다. 옵션은 다음과 같습니다.
- 모든 단일 레코드에 대해 DELETE 요청을 보냅니다 (잠재적으로 수십 개의 항목이있는 경우 나쁜 생각처럼 보입니다).
- 삭제할 ID가 URL에서 함께 묶인 DELETE를 보냅니다 (예 : "/ records / 1; 2; 3").
- 비 REST 방식으로 삭제 표시된 ID가 포함 된 사용자 지정 JSON 개체를 보냅니다.
모든 옵션이 이상적이지 않습니다.
이것은 REST 규칙의 회색 영역처럼 보입니다.
- 실행 가능한 RESTful 선택이지만 분명히 설명한 제한 사항이 있습니다.
- 이러지마 중개인은 "(단일) 리소스를에서 삭제"를 의미하는 것으로 해석합니다.
/records/1;2;3따라서 이에 대한 2xx 응답은 캐시를 제거 할 수 있습니다/records/1;2;3. 하지 제거/records/1,/records/2또는/records/3; 에 대한 410 응답을 프록시/records/1;2;3하거나 귀하의 관점에서 이해할 수없는 기타 사항을 프록시 하십시오. - 이 선택은 최선이며 RESTfully으로 수행 할 수 있습니다. API를 만들고 리소스에 대한 대량 변경을 허용하려는 경우 REST를 사용하여 수행 할 수 있지만 정확히 어떻게 많은 사람들에게 즉시 명확하지 않습니다. 한 가지 방법은 '변경 요청'리소스 를 생성 (예 :
records=[1,2,3]to 와 같은 본문을 POSTing/delete-requests)하고 생성 된 리소스 (Location응답 헤더로 지정)를 폴링 하여 요청이 수락되었는지, 거부되었는지, 진행 중인지 확인하는 것입니다. 또는 완료되었습니다. 이것은 장기 실행 작업에 유용합니다. 또 다른 방법은 목록 리소스에 요청 을 보내는PATCH것입니다 ./records, 본문에는 리소스 목록과 해당 리소스에 대해 수행 할 작업이 포함되어 있습니다 (지원하려는 형식에 관계없이). 이는 요청에 대한 응답 코드가 작업 결과를 나타낼 수있는 빠른 작업에 유용합니다.
REST의 제약 내에서 모든 것을 달성 할 수 있으며, 일반적으로 "문제"를 리소스로 만들고 URL을 제공하는 것이 답입니다.
따라서 여기에서 삭제하거나 목록에 여러 항목을 게시하거나 여러 리소스를 동일하게 편집하는 등의 일괄 작업은 모두 "일괄 작업"목록을 만들고 여기에 새 작업을 게시하여 처리 할 수 있습니다.
잊지 마세요. REST가 문제를 해결하는 유일한 방법은 아닙니다. "REST는"단지 건축 양식이고 당신은하지 않습니다 이 그것을 준수하는 (하지만 그렇게하지 않으면 당신은 인터넷의 특정 혜택을 상실). 이 HTTP API 아키텍처 목록을 살펴보고 자신에게 적합한 아키텍처 를 선택하는 것이 좋습니다. 다른 아키텍처를 선택하면 무엇을 잃는 지 스스로 인식하고 사용 사례에 따라 정보에 입각 한 결정을 내리십시오.
REST 웹 서비스에서 일괄 작업을 처리하기위한 패턴에 대한 이 질문에 대한 잘못된 답변이 있습니까? 너무 많은 찬성표를 가지고 있지만 읽어야합니다.
GET /records?filteringCriteria기준과 일치하는 모든 레코드의 배열을 반환 하면 해당 레코드를 모두 DELETE /records?filteringCriteria삭제할 수 있습니다.
이 경우 귀하의 질문에 대한 답변은입니다 DELETE /records?id=1&id=2&id=3.
Mozilla Storage Service SyncStorage API v1.5는 REST를 사용하여 여러 레코드를 삭제하는 좋은 방법이라고 생각합니다.
전체 컬렉션을 삭제합니다.
DELETE https://<endpoint-url>/storage/<collection>
단일 요청으로 컬렉션에서 여러 BSO를 삭제합니다.
DELETE https://<endpoint-url>/storage/<collection>?ids=<ids>
ids : 제공된 쉼표로 구분 된 목록에있는 ID를 가진 컬렉션에서 BSO를 삭제합니다. 최대 100 개의 ID를 제공 할 수 있습니다.
지정된 위치에서 BSO를 삭제합니다.
DELETE https://<endpoint-url>/storage/<collection>/<id>
http://moz-services-docs.readthedocs.io/en/latest/storage/apis-1.5.html#api-instructions
이것은 REST 규칙의 회색 영역처럼 보입니다.
예, 지금까지 일괄 작업 (예 : 일괄 삭제)을 언급하는 REST API 디자인 가이드 인 google api 디자인 가이드를 건너 뛰었습니다 .
이 가이드 에서는 콜론 (예 :)을 사용하여 리소스를 통해 연결할 수있는 "사용자 지정"메서드 생성에 대해 언급 합니다. https://service.name/v1/some/resource/name:customVerb또한 배치 작업을 사용 사례로 명시 적으로 언급합니다.
사용자 지정 메서드는 리소스, 컬렉션 또는 서비스와 연결될 수 있습니다. 임의의 요청을 받아 임의의 응답을 반환 할 수 있으며 스트리밍 요청 및 응답도 지원합니다. [...] 사용자 지정 메서드는 가장 유연한 의미를 가지고 있기 때문에 HTTP POST 동사를 사용해야합니다. [...] 성능이 중요한 메서드의 경우 사용자 지정 배치 메서드를 제공하여 요청 당 오버 헤드를 줄이는 것이 유용 할 수 있습니다 .
따라서 Google의 API 가이드에 따라 다음을 수행 할 수 있습니다.
POST /api/path/to/your/collection:batchDelete
... 컬렉션 리소스의 여러 항목을 삭제합니다.
나는 컬렉션의 도매 교체를 허용했습니다. 예를 들어 PUT ~/people/123/shoes본문이 전체 컬렉션 표현 인 경우.
이것은 클라이언트가 항목을 검토하고 일부를 정리하고 일부를 추가 한 다음 서버를 업데이트하려는 작은 하위 항목 컬렉션에 대해 작동합니다. 그들은 모두 삭제하기 위해 빈 컬렉션을 넣을 수 있습니다.
이것은 GET ~/people/123/shoes/9PUT가 그것을 삭제하더라도 여전히 캐시에 남아 있음을 의미 하지만 이는 단지 캐싱 문제이며 다른 사람이 신발을 삭제하면 문제가 될 것입니다.
내 데이터 / 시스템 API는 항상 만료 시간이 아닌 ETag를 사용하므로 서버가 각 요청에 맞고 데이터를 변경하려면 올바른 버전 / 동시성 헤더가 필요합니다. 읽기 전용이고보기 / 보고서가 정렬 된 API의 경우 만료 시간을 사용하여 오리진의 조회수를 줄입니다. 예를 들어 리더 보드는 10 분 동안 유용 할 수 있습니다.
같은 훨씬 더 큰 컬렉션의 ~/people경우 여러 삭제가 필요하지 않으며 유스 케이스가 자연스럽게 발생하지 않는 경향이 있으므로 단일 DELETE가 잘 작동합니다.
미래에는 REST API를 빌드하고 감사와 같은 동일한 문제와 요구 사항을 충족 한 경험을 통해 GET 및 POST 동사 만 사용하고 이벤트 주변에 디자인하는 경향이 있습니다 (예 : POST 주소 변경 이벤트). 자체 문제 세트가 함께 제공됩니다. :)
또한 엄격한 "Fielding zealot"REST API 설계를 싫어하는 실질적이고 유효한 클라이언트 측 이유가 있고 생산성 및 캐시 계층화 이유.
참고 URL : https://stackoverflow.com/questions/21863326/delete-multiple-records-using-rest
'Program Tip' 카테고리의 다른 글
| github는 프로젝트의 언어를 어떻게 알아 내나요? (0) | 2020.10.10 |
|---|---|
| Visual Studio로 TypeScript 코드 디버깅 (0) | 2020.10.10 |
| 인간을위한 JAAS (0) | 2020.10.10 |
| Qt LGPL 라이선스를 사용하고 어떤 제한없이 내 애플리케이션을 판매 할 수 있습니까? (0) | 2020.10.10 |
| 노드 작업 대기열에서 콜백 목록을 얻으려면 어떻게해야합니까? (0) | 2020.10.10 |