여러 항목을 삭제하는 REST-ful 방법은 무엇입니까?
내 사용 사례는 한 번에 여러 항목을 삭제할 수 있어야하는 백본 컬렉션이 있다는 것입니다. 옵션은 다음과 같습니다.
모든 옵션이 이상적이지 않습니다.
이것은 REST 규칙의 회색 영역처럼 보입니다.
답변:
/records/1;2;3따라서 이에 대한 2xx 응답으로 인해 캐시를 제거 할 수 있습니다 /records/1;2;3. 하지 제거 /records/1, /records/2또는 /records/3; 에 대한 410 응답을 프록시 /records/1;2;3하거나 귀하의 관점에서 이해할 수없는 기타 사항을 프록시 하십시오.records=[1,2,3]to 와 같은 본문을 POSTing /delete-requests)하고 생성 된 리소스 ( Location응답 헤더로 지정)를 폴링 하여 요청이 수락되었는지, 거부되었는지, 진행 중인지 확인하는 것입니다. 또는 완료되었습니다. 이것은 장기 실행 작업에 유용합니다. 또 다른 방법은 목록 리소스에 요청 을 보내는PATCH 것입니다 ./records, 본문에는 리소스 목록과 해당 리소스에 대해 수행 할 작업이 포함됩니다 (지원하려는 형식에 관계없이). 이는 요청에 대한 응답 코드가 작업 결과를 나타낼 수있는 빠른 작업에 유용합니다.REST의 제약 내에서 모든 것을 달성 할 수 있으며 일반적으로 "문제"를 리소스로 만들고 URL을 제공하는 것이 답입니다.
따라서 여기에서 삭제하거나 목록에 여러 항목을 게시하거나 리소스를 동일하게 편집하는 등의 일괄 작업은 모두 "일괄 작업"목록을 만들고 여기에 새 작업을 게시하여 처리 할 수 있습니다.
잊지 마세요. REST가 문제를 해결하는 유일한 방법은 아닙니다. "REST는"단지 건축 양식이고 당신은하지 않습니다 이 그것을 준수하는 (하지만 그렇게하지 않으면 당신은 인터넷의 특정 혜택을 상실). 이 HTTP API 아키텍처 목록을 살펴보고 자신에게 적합한 아키텍처 를 선택하는 것이 좋습니다. 다른 아키텍처를 선택하면 잃어버린 부분을 인식하고 사용 사례에 따라 정보에 입각 한 결정을 내리십시오.
REST 웹 서비스에서 일괄 작업을 처리하기위한 패턴에 대한 이 질문에 대한 잘못된 답변이 있습니까? 너무 많은 찬성표를 가지고 있지만 읽어야합니다.
DELETE요청 을 발행 하면 요청자와 서버 사이에있는 모든 것이 지정된 URL에서 단일 리소스가 삭제되고 있다고 생각합니다. 쿼리 문자열은 이러한 장치에 대한 URL의 불투명 한 부분이므로 API를 지정하는 방법은 중요하지 않으며이 지식에 대한 권한이 없으므로 다르게 동작 할 수 없습니다.
DELETE것은 금지되어 있다고 말할 것 입니다. 하지마. 당신이 그렇게한다면 나는 당신의 아이들을 먹을 것입니다. Nom nom nom.
GET /records?filteringCriteria기준과 일치하는 모든 레코드의 배열을 반환 하면 해당 레코드를 모두 DELETE /records?filteringCriteria삭제할 수 있습니다.
이 경우 귀하의 질문에 대한 답변은입니다 DELETE /records?id=1&id=2&id=3.
GET /records?id=1&id=2&id=3"ID가 1, 2, 3 인 레코드 3 개 가져 오기" 가 아니라 "URL 경로가 / records? id = 1 & id = 2 & id = 3 인 단일 리소스 가져 오기"를 의미합니다. 이는 순무 그림, 일반 텍스트 일 수 있습니다. 중국어로 숫자 "42"가 포함 된 문서 또는 존재하지 않을 수 있습니다.
/records?id=1및 /records?id=2에 대한 두 개의 순차적 요청 이 전송되고 해당 응답이 일부 중개자 (예 : 브라우저 또는 ISP)에 의해 캐시됩니다. 인터넷이 애플리케이션이 의미하는 바를 알고 있다면 /records?id=1&id=2원본 서버에 묻지 않고 이미 가지고있는 두 결과를 병합 (어떻게 든)하여 캐시 에서 요청을 반환 할 수 있다는 이유를 알 수 있습니다. 그러나 이것은 불가능합니다. /records?id=1&id=2유효하지 않거나 (요청 당 하나의 ID 만 허용됨) 완전히 다른 것을 반환 할 수 있습니다 (순무).
id[]=1&id[]=2하거나 id=1&id=2쿼리 문자열에서 해당 쿼리 문자열을 사용하는지 여부에 관계없이 해당 쿼리 문자열은이를 나타냅니다. 그리고 쿼리 문자열이 필터를 나타내는 것이 매우 일반적이고 좋은 습관이라고 생각합니다. 또한 삭제 및 업데이트를 허용하는 경우 GET요청을 캐시하지 마십시오 . 그렇게하면 클라이언트가 부실 상태를 유지합니다.
Mozilla Storage Service SyncStorage API v1.5는 REST를 사용하여 여러 레코드를 삭제하는 좋은 방법이라고 생각합니다.
DELETE https://<endpoint-url>/storage/<collection>DELETE https://<endpoint-url>/storage/<collection>?ids=<ids>ids : 제공된 쉼표로 구분 된 목록에있는 ID를 가진 컬렉션에서 BSO를 삭제합니다. 최대 100 개의 ID를 제공 할 수 있습니다.
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... 컬렉션 리소스의 여러 항목을 삭제합니다.
If the HTTP verb used for the custom method does not accept an HTTP request body (GET, DELETE), the HTTP configuration of such method must not use the body clause at all,가 Custom Method 장에서 언급 한 것이 흥미 롭습니다 . 그러나 GET accounts.locations.batchGetAPI는 본문이있는 GET 메소드입니다. 이상합니다. developers.google.com/my-business/reference/rest/v4/...
POSThttp 메소드이며 사용자 정의 메소드 만 명명 batchGet됩니다. 나는 Google이 (a) 모든 사용자 정의 방법이 있어야한다는 규칙을 고수하고 POST(내 대답 참조) (b) 사람들이 본문에 "필터"를 더 쉽게 넣을 수 있도록하기 위해 그렇게한다고 생각합니다. 쿼리 문자열과 마찬가지로 필터를 이스케이프하거나 인코딩합니다. 단점은 물론,이 ... 더 이상 정말 캐시되지 않는 것입니다
https://service.name/v1/some/resource/name:customVerb정의상 RESTful이 아닙니다.
나는 컬렉션의 도매 교체를 허용했습니다. 예를 들어 PUT ~/people/123/shoes본문이 전체 컬렉션 표현 인 경우.
이는 클라이언트가 항목을 검토하고 일부를 정리하고 일부를 추가 한 다음 서버를 업데이트하려는 작은 하위 항목 컬렉션에 대해 작동합니다. 그들은 모두 삭제하기 위해 빈 컬렉션을 넣을 수 있습니다.
이것은 GET ~/people/123/shoes/9PUT가 그것을 삭제하더라도 여전히 캐시에 남아 있음을 의미 하지만 이는 단지 캐싱 문제이며 다른 사람이 신발을 삭제하면 문제가 될 것입니다.
내 데이터 / 시스템 API는 항상 만료 시간이 아닌 ETag를 사용하므로 서버는 각 요청에 맞고 데이터를 변경하려면 올바른 버전 / 동시성 헤더가 필요합니다. 읽기 전용이고보기 / 보고서가 정렬 된 API의 경우 만료 시간을 사용하여 오리진의 조회수를 줄입니다. 예를 들어 리더 보드는 10 분 동안 유용 할 수 있습니다.
같은 훨씬 더 큰 컬렉션의 ~/people경우 여러 삭제가 필요하지 않으며 유스 케이스가 자연스럽게 발생하지 않는 경향이 있으므로 단일 DELETE가 잘 작동합니다.
미래에는 REST API를 구축하고 감사와 같은 동일한 문제와 요구 사항을 충족 한 경험을 통해 GET 및 POST 동사와 이벤트에 대한 디자인 만 사용하는 경향이 있습니다 (예 : POST 주소 변경 이벤트). 자체 문제 세트가 함께 제공됩니다. :)
또한 엄격한 "Fielding zealot"REST API 설계를 싫어하는 실질적이고 유효한 클라이언트 측 이유가 있고 생산성 및 생산성을 위해 프런트 엔드 개발자가 더 엄격한 백엔드 API를 사용하는 자체 API를 구축 할 수 있도록 허용합니다. 캐시 계층화 이유.