REST, HTTP DELETE e parâmetros

Existe algo não RESTful no fornecimento de parâmetros para uma solicitação HTTP DELETE?

Meu cenário é que estou modelando o "Tem certeza de que deseja excluir isso?" cenário. Em alguns casos, o estado do recurso sugere que a exclusão solicitada pode ser inválida. Você provavelmente pode imaginar alguns cenários em que a confirmação de uma exclusão é necessária

A solução que adotamos é passar um parâmetro para a solicitação de exclusão para indicar que não há problema em prosseguir com a exclusão ("? Force_delete = true")

por exemplo

DELETE http://server/resource/id?force_delete=true

Eu acredito que ainda é tranquilo desde:

(a) A semântica de DELETE não está sendo alterada - o usuário ainda pode enviar uma solicitação DELETE normal, mas isso pode falhar com 409 e o corpo da resposta explica o porquê. Eu digo que pode falhar porque (por razões que não valem a pena explicar) em algumas ocasiões, não há motivos para solicitar ao usuário.

(b) Não há nada na dissertação de Roy que sugira que seja contra o espírito do REST - por que haveria uma vez que o HTTP é apenas uma implementação do REST, por que os parâmetros HTTP passantes são importantes

Alguém pode me indicar uma declaração definitiva que identifique o motivo pelo qual isso não é RESTful?

Em uma pergunta relacionada, se o usuário não especificar force_delete, retornarei 409 Conflict- esse é o código de resposta mais apropriado?

Acompanhamento

Após algumas pesquisas, acho que adicionar parâmetros ao DELETE pode violar vários princípios.

A primeira é que a implementação possivelmente viola a "Interface Uniforme" (consulte a seção 5.1.5 da dissertação de Roy

Ao adicionar 'force_delete', adicionamos uma restrição adicional ao método DELETE já bem definido. Essa restrição é significativa apenas para nós.

Você também pode argumentar que isso viola o "5.1.2 Client-Server", pois o diálogo de confirmação é realmente uma preocupação da interface do usuário e, novamente, nem todos os clientes desejam confirmar a exclusão.

Sugestões alguém?

Não, não é RESTful. A única razão pela qual você deve colocar um verbo ( force_delete) no URI é se você precisa sobrecarregar os métodos GET / POST em um ambiente em que os métodos PUT / DELETE não estão disponíveis. A julgar pelo uso do método DELETE, esse não é o caso.

O código de erro HTTP 409/Conflictdeve ser usado para situações em que existe um conflito que impede o serviço RESTful de executar a operação, mas ainda existe a chance de o usuário conseguir resolver o conflito sozinho. Uma confirmação de pré-exclusão (onde não há conflitos reais que impediria a exclusão) não é um conflito em si, pois nada impede a API de executar a operação solicitada.

Como Alex disse (não sei quem recusou, ele está correto), isso deve ser tratado na interface do usuário, porque um serviço RESTful, como tal, apenas processa solicitações e, portanto, não tem estado (ou seja, não deve depender de confirmações mantendo qualquer informação do servidor sobre uma solicitação).

Dois exemplos de como fazer isso na interface do usuário seriam:

• pre-HTML5 : * mostra uma caixa de diálogo de confirmação JS ao usuário e envia a solicitação somente se o usuário confirmar
• HTML5 : * use um formulário com a ação DELETE, onde o formulário conteria apenas os botões "Confirmar" e "Cancelar" ("Confirmar" seria o botão Enviar)

(*) Observe que as versões HTML anteriores a 5 não oferecem suporte a métodos HTTP PUT e DELETE nativamente, no entanto, os navegadores mais modernos podem executar esses dois métodos por meio de chamadas AJAX. Consulte este tópico para obter detalhes sobre o suporte entre navegadores.

Atualização (com base em investigações e discussões adicionais):

O cenário em que o serviço exigiria a force_delete=truepresença da bandeira viola a interface uniforme, conforme definida na dissertação de Roy Fielding. Além disso, conforme RFC HTTP , o método DELETE pode ser substituído no servidor de origem (cliente), o que implica que isso não é feito no servidor de destino (serviço).

Portanto, uma vez que o serviço receba uma solicitação DELETE, deve processá-la sem precisar de confirmação adicional (independentemente de o serviço realmente executar a operação).

Eu acho que isso não é repousante. Não acho que o serviço reparador deva lidar com o requisito de forçar o usuário a confirmar uma exclusão. Eu lidaria com isso na interface do usuário.

Especificar force_delete = true faz sentido se essa for a API de um programa? Se alguém estivesse escrevendo um script para excluir este recurso, você gostaria de forçá-lo a especificar force_delete = true para realmente excluir o recurso?

É uma pergunta antiga, mas aqui estão alguns comentários ...

1. No SQL, o comando DELETE aceita um parâmetro "CASCADE", que permite especificar que os objetos dependentes também devem ser excluídos. Este é um exemplo de um parâmetro DELETE que faz sentido, mas 'man rm' pode fornecer outros. Como esses casos poderiam ser implementados no REST / HTTP sem um parâmetro?
2. @ Jan, parece ser uma convenção bem estabelecida que a parte do caminho da URL identifique um recurso, enquanto a string de consulta não (pelo menos não necessariamente). São muitos os exemplos: obter o mesmo recurso, mas em um formato diferente, obter campos específicos de um recurso etc. Se considerarmos a sequência de consultas como parte do identificador do recurso, é impossível ter um conceito de "visualizações diferentes do mesmo recurso" sem recorrer a mecanismos não RESTful, como negociação de conteúdo HTTP (que pode ser indesejável por vários motivos).

Além da resposta de Alex:

Observe que http: // server / resource / id? Force_delete = true identifica um recurso diferente de http: // server / resource / id . Por exemplo, é uma enorme diferença se você exclui / customers /? Status = old ou / customers /.

Jan