Exclua vários registros usando REST

Qual é a maneira REST completa de excluir vários itens?

Meu caso de uso é que tenho uma coleção de backbone em que preciso ser capaz de excluir vários itens de uma vez. As opções parecem ser:

1. Envie uma solicitação DELETE para cada registro (o que parece uma má ideia se houver potencialmente dezenas de itens);
2. Envie um DELETE onde os IDs a serem excluídos estão agrupados na URL (ou seja, "/ records / 1; 2; 3");
3. De forma não REST, envie um objeto JSON personalizado contendo os IDs marcados para exclusão.

Todas as opções são menos do que ideais.

Esta parece ser uma área cinzenta da convenção REST.

1. É uma escolha RESTful viável, mas obviamente possui as limitações que você descreveu.
2. Não faça isso. Isso seria interpretado pelos intermediários como significando “EXCLUIR o (único) recurso em /records/1;2;3” - Portanto, uma resposta 2xx a isso pode fazer com que eles limpem o cache /records/1;2;3; não purga /records/1, /records/2ou /records/3; proxy para uma resposta 410 /records/1;2;3, ou outras coisas que não fazem sentido do seu ponto de vista.
3. Essa escolha é a melhor e pode ser feita RESTLY. Se você está criando uma API e deseja permitir mudanças em massa nos recursos, pode usar REST para fazer isso, mas exatamente como não é imediatamente óbvio para muitos. Um método é criar um recurso de 'solicitação de mudança' (por exemplo, postando um corpo como records=[1,2,3]to /delete-requests) e pesquisar o recurso criado (especificado pelo Locationcabeçalho da resposta) para descobrir se sua solicitação foi aceita, rejeitada ou está em andamento ou foi concluído. Isso é útil para operações de longa duração. Outra forma é enviar uma PATCHsolicitação ao recurso de lista ,/records, cujo corpo contém uma lista de recursos e ações a serem executadas nesses recursos (em qualquer formato que você deseja oferecer suporte). Isso é útil para operações rápidas em que o código de resposta da solicitação pode indicar o resultado da operação.

Tudo pode ser conseguido mantendo-se dentro das restrições de REST, e geralmente a resposta é transformar o "problema" em um recurso e fornecer a ele uma URL.
Portanto, operações em lote, como excluir aqui, ou POSTAR vários itens em uma lista, ou fazer a mesma edição em uma faixa de recursos, podem ser manipuladas criando uma lista de "operações em lote" e POSTANDO sua nova operação nela.

Não se esqueça, REST não é a única maneira de resolver qualquer problema. “REST” é apenas um estilo arquitetônico e você não precisa aderir a ele (mas você perde alguns benefícios da Internet se não o fizer). Eu sugiro que você dê uma olhada nesta lista de arquiteturas de API HTTP e escolha aquela que mais se adequa a você. Apenas fique ciente do que você perderá se escolher outra arquitetura e tome uma decisão informada com base em seu caso de uso.

Existem algumas respostas ruins para esta pergunta sobre Padrões para manipulação de operações em lote em serviços da Web REST? que têm muitos votos positivos, mas devem ser lidos também.

Se GET /records?filteringCriteriaretornar a matriz de todos os registros que correspondem aos critérios, DELETE /records?filteringCriteriapoderá excluir todos esses registros.

Nesse caso, a resposta à sua pergunta seria DELETE /records?id=1&id=2&id=3.

Acho que o Mozilla Storage Service SyncStorage API v1.5 é uma boa maneira de excluir vários registros usando REST.

Exclui uma coleção inteira.

DELETE https://<endpoint-url>/storage/<collection>

Exclui vários BSOs de uma coleção com uma única solicitação.

DELETE https://<endpoint-url>/storage/<collection>?ids=<ids>

ids : exclui BSOs da coleção cujos ids estão na lista separada por vírgulas fornecida. Um máximo de 100 ids podem ser fornecidos.

Exclui o BSO no local fornecido.

DELETE https://<endpoint-url>/storage/<collection>/<id>

http://moz-services-docs.readthedocs.io/en/latest/storage/apis-1.5.html#api-instructions

Esta parece ser uma área cinzenta da convenção REST.

Sim, até agora só encontrei um guia de design da API REST que menciona operações em lote (como uma exclusão de lote): o guia de design da API do Google .

Este guia menciona a criação de métodos "personalizados" que podem ser associados por meio de um recurso usando dois-pontos, por exemplo https://service.name/v1/some/resource/name:customVerb, também menciona explicitamente operações em lote como caso de uso:

Um método personalizado pode ser associado a um recurso, coleção ou serviço. Pode levar uma solicitação arbitrária e retornar uma resposta arbitrária e também oferece suporte a solicitação e resposta de streaming. Os métodos [...] personalizados devem usar o verbo HTTP POST, uma vez que tem a semântica mais flexível [...] Para métodos críticos de desempenho, pode ser útil fornecer métodos de lote personalizados para reduzir a sobrecarga por solicitação .

Portanto, você pode fazer o seguinte de acordo com o guia de API do Google:

POST /api/path/to/your/collection:batchDelete

... para deletar vários itens do seu recurso de coleção.

Permiti uma substituição total de uma coleção, por exemplo, PUT ~/people/123/shoesonde o corpo é a representação da coleção inteira.

Isso funciona para pequenas coleções filho de itens em que o cliente deseja revisar os itens e remover alguns e adicionar outros e, em seguida, atualizar o servidor. Eles podem PUT uma coleção vazia para deletar tudo.

Isso significaria GET ~/people/123/shoes/9que ainda permaneceria no cache mesmo que um PUT o excluísse, mas isso é apenas um problema de cache e seria um problema se outra pessoa excluísse o sapato.

Minhas APIs de dados / sistemas sempre usam ETags em vez de tempos de expiração para que o servidor seja atingido em cada solicitação e eu exijo os cabeçalhos de versão / simultaneidade corretos para alterar os dados. Para APIs que são somente leitura e alinhadas com visualização / relatório, eu uso tempos de expiração para reduzir ocorrências na origem, por exemplo, um placar pode durar 10 minutos.

Para coleções muito maiores, como ~/people, tendo a não precisar de várias exclusões, o caso de uso tende a não surgir naturalmente e, portanto, um único DELETE funciona bem.

No futuro, e por experiência com a construção de APIs REST e enfrentando os mesmos problemas e requisitos, como auditoria, eu estaria inclinado a usar apenas verbos GET e POST e projetar em torno de eventos, por exemplo, POST um evento de mudança de endereço, embora eu suspeite que virá com seu próprio conjunto de problemas :)

Eu também permitiria que os desenvolvedores de front-end criassem suas próprias APIs que consomem APIs de back-end mais rígidas, uma vez que muitas vezes há razões práticas e válidas do lado do cliente pelas quais eles não gostam de designs de API REST estritos "fanáticos por Fielding" e para produtividade e motivos de camadas de cache.