Où gérer une action de restauration dans une application REST MVC ?

Question

Après avoir détruit une ressource dans mon application Rails, l'utilisateur peut la restaurer en cliquant sur un lien.

Actuellement, cette action de restauration est acheminée vers la méthode destroy du contrôleur de ressources correspondant.

Lorsque cette méthode trouve la ressource dans la base de données, elle la détruit et déplace l'enregistrement dans une table poubelle.

Lorsqu'il ne trouve pas la ressource dans la base de données, il la recherche dans la table poubelle et s'il trouve la ressource, il la restaure.

Je ne suis pas très satisfait de cette façon de faire, la méthode destroy ayant deux objectifs :détruire et restaurer.

Je pourrais créer une action de restauration dédiée dans mon contrôleur, mais de manière REST, où placeriez-vous la gestion des demandes de restauration ?Dans un contrôleur dédié ?Si oui, avec quelle méthode, PUT ou POST ?

Answer 1

POST n'est pas idempotent, ce qui signifie que si vous envoyez plusieurs fois la même requête POST, vous obtiendrez de nombreux nouveaux éléments.PUT doit être idempotent, puisque la même mise à jour effectuée sur la même ressource ne devrait avoir aucun effet secondaire lorsqu'elle est exécutée plusieurs fois.

Quant à savoir où doit aller cette action, cela dépend vraiment de votre sensibilité esthétique et de la façon dont vous voulez être inconditionnel à propos de REST plutôt que de garder vos contrôleurs Rails propres et bien organisés.

On peut certainement soutenir qu'un DeletedBob est une ressource différente d'un Bob.Vous pourriez dire qu'un PUT envoyé au DeletedBobsController mettrait à jour la ressource DeletedBob, peut-être avec un paramètre comme "deleted=false" pour indiquer le but de la mise à jour.

Vous pouvez également considérer les suppressions comme une ressource.Ensuite, vous pouvez utiliser DELETE sur le DeletionsController avec les paramètres "resource_type=bob&resource_id=23".En détruisant la suppression, vous restaurez l'objet d'origine.Les appels identiques ultérieurs produiront une erreur "objet non trouvé", comme on peut s'y attendre avec DELETE.

Personnellement, depuis que Roy Fielding (auteur original de la thèse définissant REST) ​​a déclaré qu'il y avait vraiment rien de mal avec POST, j'envisagerais de définir un paramètre supplémentaire :put => :restore méthode et itinéraire sur mon BobsController.Il conserve le code là où un autre programmeur l'attendrait, et ils sont probablement le seul public pour ce type de conception.

Answer 2

Je pense qu'un puriste REST créerait une nouvelle ressource appelée Trash qui est gérée par un TrashController. Pour gérer une restauration, vous auriez appelé une action sur la restauration TrashController.

L'URL ressemblerait à ceci:

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

Answer 3

Je pense que puisque l'action est sur une ressource, la fonctionnalité devrait vivre dans la ResourceController. Un de mes understadings travail d'une architecture RESTFUL est qu'une règle de base sur la décision entre PUT et POST est que le POST est utilisé pour créer et PUT est utilisé pour les mises à jour. Dans ce cas, j'attendre à ce que la ressource « existe » et que vous le mettez à jour son état que votre utiliserait un PUT et la restauration URI serait quelque chose comme:

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

Answer 4

Je pense que Sean était au-dessus sur la bonne voie, mais je prendrais un peu plus loin. Faire l'action trash un POST qui met à jour la ressource avec trash=1. Ensuite, la restauration est juste une autre POST au même ressource avec trash=0

EDIT:. Remplacée PUT méthode incorrecte avec POST donné la demande n'envoie pas la totalité de la ressource, juste une mise à jour d'une partie de la ressource