Onde lidar com uma ação de restauração em um aplicativo REST MVC?

Question

Depois de destruir um recurso na minha aplicação Rails, o usuário pode restaurá-lo clicando em um link.

Atualmente esta ação de restauração é encaminhado para o método destroy do controlador de recursos correspondente.

Quando este método encontra o recurso no banco de dados, ele destrói-o e move o registro em uma tabela de lixo.

Quando não encontrar o recurso no banco de dados, ele procura-lo na tabela de lixo e se encontra o recurso que restaura-lo.

Não estou muito satisfeito por esta forma de fazer, com o método de destruir ter duas finalidades:. Destruir e restaurar

Eu poderia criar uma ação de restauração dedicado no meu controlador, mas de uma forma REST, onde você colocaria a solicitação de movimentação restaurar? Em um controlador dedicado? Se assim for, com que método, PUT ou POST?

Answer 1

POST não é idempotente, ou seja, se você enviar o mesmo pedido POST muitas vezes, você vai ter muitos novos itens. PUT deve ser idempotentes, já que a mesma atualização acontecendo no mesmo recurso não deve ter efeitos colaterais quando executado várias vezes.

Como para onde esta ação deve ir, ele realmente depende do seu pela sensibilidade estética e como incondicional você quer ser sobre o REST contra mantendo seus controladores Rails limpo e bem organizado.

É certamente discutível que um DeletedBob é um recurso diferente de um Bob. Pode-se dizer que uma PUT enviado para o DeletedBobsController vai atualizar o recurso DeletedBob, talvez com um parâmetro como "excluído = false" para indicar o propósito da atualização.

Você também pode considerar Eliminações como um recurso. Em seguida, você poderia usar DELETE no DeletionsController com o params "resource_type = bob & RESOURCE_ID = 23". Ao destruir a eliminação, que está a restaurar o objeto original. chamadas idênticas subsequentes irá produzir um erro "objeto não encontrado", como seria de esperar, com DELETE.

Pessoalmente, desde que Roy Fielding (autor original do resto definindo dissertação) saiu e disse que não há realmente errado nada com POST , eu consideraria a definição de um método :put => :restore adicional e via no meu BobsController. Ele mantém o código onde outro programador seria de esperar, e que são susceptíveis a única audiência para este tipo de projeto.

Answer 2

Eu acho que um purista RESTO iria criar um novo recurso chamado lixo que é tratado por um TrashController. Para lidar com uma restauração, você teria uma ação em TrashController chamado Restore.

O URL ficaria assim:

http://example.com/trash/restore/{resourceId}

Answer 3

Eu acho que desde que a ação está em um recurso, a funcionalidade deve viver no ResourceController. Um dos meus understadings de trabalho de uma arquitetura RESTful é que uma regra de ouro em decidir entre PUT e POST é que POST é usado para cria e PUT é usado para atualizações. Neste caso, seria de esperar que o recurso 'existe' e você está atualizando seu estado que o seu usaria um PUT e a restauração URI seria algo como:

http://example.com/resources/restore/ {id}

Answer 4

Eu acho que Sean acima estava no caminho certo, mas eu iria levá-la um passo adiante. Faça a ação lixo um POST que atualiza o recurso com trash=1. Em seguida, restaurar é apenas mais um POST ao mesma recurso com trash=0

EDIT:. Substituído PUT método incorreto com POST dada a solicitação não está enviando todo o recurso, apenas uma atualização de uma parte do recurso