REPOS, HTTP DELETE et paramètres

Question

Est-il quelque chose de non-Reposant sur le fait de fournir des paramètres à une HTTP SUPPRIMER la demande?

Mon scénario, c'est que je suis à la modélisation de l' "Êtes-vous sûr de vouloir supprimer?" scénario. Dans certains cas, l'état de la ressource suggère que la demande de suppression peut être invalide. Vous pouvez probablement imaginer des scénarios de vous-même, où la confirmation de suppression est nécessaire

La solution que nous avons adoptée est de passer un paramètre à la demande de suppression pour indiquer que c'est ok pour procéder à la suppression ("?force_delete=true")

par exemple

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

Je crois que c'est toujours reposant depuis:

(a) La sémantique de SUPPRIMER ne sont pas modifiés: l'utilisateur peut toujours envoyer un demande de SUPPRESSION, mais cela peut échouer avec 409 et le corps de la réponse vais expliquer pourquoi. Je dis peut échouer parce que (pour des raisons qui n'en vaut pas expliquer) à certaines occasions, il n'y a aucune raison de demander à l'utilisateur.

(b) Il n'y a rien de Roy thèse de penser que c'est contre l'esprit du RESTE - pourquoi y aurait-il depuis l'adresse HTTP est un seul de la mise en œuvre de REPOS, alors pourquoi passer des paramètres HTTP matière

Quelqu'un peut me pointer à une déclaration définitive d'ongles que la raison pour laquelle ce n'est pas Reposante?

Sur une question connexe, si l'utilisateur ne spécifie pas de force_delete alors je suis de retour 409 Conflict - , c'est que la réponse la plus appropriée code?

Suivi

Après quelques recherches, je pense que l'ajout de paramètres pour le SUPPRIMER peut violer à plusieurs principes.

La première est que la mise en œuvre, éventuellement, viole la "Interface Uniforme" (voir le paragraphe 5.1.5 du Roy thèse

En ajoutant 'force_delete" nous sommes en ajoutant une contrainte supplémentaire sur le déjà bien défini la méthode DELETE. Cette contrainte n'a de sens que pour nous.

Vous pouvez aussi argumenter qu'il viole la "5.1.2 Client-Serveur" depuis la boîte de dialogue de confirmation est vraiment une préoccupation de l'INTERFACE utilisateur et encore, pas tous les clients voudront confirmer la suppression.

Suggestions de quelqu'un?

Answer 1

Non, il n'est pas de tout repos. La seule raison pourquoi vous devriez mettre un verbe (force_delete) dans l'URI est si vous avez besoin de surcharger GET/POST méthodes dans un environnement où il PUT/DELETE méthodes ne sont pas disponibles. À en juger par votre utilisation de la méthode de SUPPRESSION, ce n'est pas le cas.

Code d'erreur HTTP 409/Conflict doit être utilisé pour les situations où il existe un conflit qui empêche le service RESTful pour effectuer l'opération, mais il ya encore une chance que l'utilisateur peut être en mesure de résoudre le conflit lui-même. Un pré-confirmation de la suppression (où il n'y a pas de réels conflits qui permettrait d'éviter la suppression) n'est pas un conflit en soi, car rien n'empêche l'API à partir d'effectuer l'opération demandée.

Comme Alex l'a dit (je ne sais pas qui downvoted lui, il est correct), cela devrait être géré dans l'INTERFACE utilisateur, car un service RESTful que ce processus de demandes et devrait donc être apatrides (c'est à dire qu'il ne doit pas compter sur les confirmations par la tenue de tout côté serveur de l'information au sujet d'une demande).

Deux exemples de la façon de faire dans l'INTERFACE utilisateur:

• pré-HTML5:* afficher un JS boîte de dialogue de confirmation à l'utilisateur, et d'envoyer la demande seulement si l'utilisateur confirme qu'il
• HTML5:* utiliser un formulaire avec l'action de SUPPRESSION où la forme ne contiendra que "Valider" et "Annuler" boutons"Valider" serait le bouton "soumettre")

(*) Veuillez noter que les versions HTML avant le 5 ne prennent pas en charge PUT et DELETE méthodes en natif, cependant la plupart des navigateurs modernes peuvent faire ces deux méthodes via des appels AJAX. Voir ce fil pour plus de détails sur la prise en charge du navigateur.

---

Mise à jour (sur la base de nouvelles enquêtes et de discussions):

Le scénario où le service nécessiterait l' force_delete=true pavillon à être présent viole l' interface uniforme tel que défini dans Roy Fielding de la thèse. Aussi, comme par HTTP RFC, la SUPPRESSION de la méthode peut être redéfinie sur le serveur d'origine (client), ce qui implique que ce n'est pas fait sur le serveur cible (service).

Donc, une fois que le service reçoit une demande de SUPPRESSION, il doit la traiter sans avoir besoin d'une confirmation supplémentaire (peu importe si le service effectue l'opération).

Answer 2

Je pense que c’est non-réparateur. Je ne pense pas que le service restful doit gérer l’exigence d’obliger l’utilisateur à confirmer la suppression. Je voudrais gérer cela dans l’interface utilisateur.

Does spécifiant force_delete = true de sens s’il s’agissait d’API un programme ? Si quelqu'un a écrit un script pour supprimer cette ressource, vous voulez forcer à spécifier force_delete = true pour supprimer la ressource ?

Answer 3

C'est une vieille question, mais voici quelques commentaires...

1. En SQL, la commande SUPPRIMER accepte un paramètre de la "CASCADE", qui permet de spécifier que les objets qui en dépendent doivent également être supprimés. Ceci est un exemple de SUPPRIMER un paramètre qui fait sens, mais "l'homme rm" pourrait fournir d'autres. Comment ces cas qui pourraient être mis en œuvre en REST/HTTP sans paramètre?
2. @Jan, il semble être bien établie de la convention que le chemin d'accès à la partie de l'URL qui identifie une ressource, alors que la chaîne de requête n'est pas (au moins pas nécessairement). Les exemples ne manquent pas: arriver à la même ressource, mais dans un format différent, l'obtention des domaines spécifiques de la ressource, etc. Si l'on considère la chaîne de requête dans le cadre de l'identificateur de ressource, il est impossible d'avoir un concept de "vues différentes de la même ressource" sans se tourner vers le non-Sommeil des mécanismes tels que la négociation de contenu HTTP (qui peut être indésirable pour de nombreuses raisons).

Answer 4

En plus de la réponse d’Alex :

Notez que http://server/resource/id?force_delete=true identifie une ressource différente que http://server/resource/id. Par exemple, il y a une énorme différence si vous supprimez /customers/ ? statut = vieux ou/clients /.

Jan