Supprimer une ressource à l'aide de http DELETE

Donc, étant donné que le verbe DELETE dans Http est idempotent, lorsque j'émets la requête suivante, que doit-il se passer le deuxième (ou troisième, ou quatrième, etc ...)?

DELETE /person/123

La première fois, la ressource est supprimée et je renvoie un 204 (réussi, pas de contenu). Dois-je renvoyer un 204 lors d'appels ultérieurs ou un 404 (introuvable)?

Comme les requêtes HTTP dans un système sans état doivent être indépendantes, les résultats d'une requête ne doivent pas dépendre d'une requête précédente. Considérez ce qui devrait se passer si deux utilisateurs effectuaient un DELETE sur la même ressource simultanément. Il est logique que la deuxième demande obtienne un 404. La même chose devrait être vraie si un utilisateur fait deux demandes.

Je suppose qu'avoir DELETE renvoyer deux réponses différentes ne vous semble pas idempotent. Je trouve utile de penser aux demandes idempotentes comme laissant le système dans le même état, sans nécessairement avoir la même réponse. Ainsi, que vous supprimiez une ressource existante ou que vous tentiez de SUPPRIMER une ressource qui n'existe pas, l'état des ressources du serveur est le même.

Le livre de recettes des services Web RESTful est une excellente ressource pour cela. Par chance, son aperçu google affiche la page sur DELETE (page 11):

La méthode DELETE est idempotente. Cela implique que le serveur doit renvoyer le code de réponse 200 (OK) même si le serveur a supprimé la ressource dans une requête précédente. Mais en pratique, la mise en œuvre de DELETE en tant qu'opération idempotente nécessite que le serveur garde une trace de toutes les ressources supprimées. Sinon, il peut renvoyer un 404 (non trouvé).

Je suis d'accord avec ce que la réponse choisie actuelle a dit, que le 2e (et 3e, 4e, ...) SUPPRIMER devrait obtenir un 404 . Et, j'ai remarqué que la réponse avait 143 votes positifs, mais aussi un commentaire opposé qui a 54 votes positifs, de sorte que la communauté est divisée en 2 camps dans un rapport d'environ 3: 1. Voici plus d'informations pour régler ce débat de longue date.

1. Tout d'abord, ne commençons PAS par ce que «je» pense, ce que «vous» pensez ou ce qu'un autre auteur de livre pense. Commençons par les spécifications HTTP, c'est-à-dire RFC 7231.

   • La RFC 7231, section 4.3.5 DELETE est arrivée à mentionner seulement qu'une réponse réussie devrait être 2xx, mais elle n'a pas appelé ce qu'un DELETE ultérieur obtiendrait. Alors creusons plus profondément.
   • RFC 7231, section 6.5.4 404 Not Found indique que la réponse 404 est pour une ressource n'existe pas. Puisqu'aucune méthode http spécifique (en particulier, pas DELETE) n'est appelée pour être traitée autrement, nous pouvons intuitivement avoir l'impression (et à juste titre), que ma requête DELETE /some/resource/which/does/not/existdevrait aboutir à un 404. Ensuite, DELETE /some/resource/which/happened/to/be/removed/by/someone/else/five/days/agopourrait aussi bien renvoyer un 404 Alors, pourquoi devrait-il DELETE /some/resource/i/deleted/five/seconds/agoêtre différent? "Mais qu'en est-il de l'idempotence?!", Je peux vous entendre crier ça. Attendez, nous sommes sur le point d'entrer dans cela.

   • Historiquement, la RFC 2616, publiée en 1999, était la spécification HTTP 1.1 la plus référencée. Malheureusement sa description de l'idempotence était vague , ce qui laisse place à tous ces débats. Mais cette spécification a été remplacée par la RFC 7231. Cité de la RFC 7231, section 4.2.2 Méthodes idempotentes , je souligne:

     Une méthode de demande est considérée comme "idempotente" si l'EFFET prévu SUR LE SERVEUR de plusieurs demandes identiques avec cette méthode est le même que l'effet pour une seule demande de ce type. Parmi les méthodes de demande définies par cette spécification, les méthodes de demande PUT, DELETE et sûres sont idempotentes .

     Donc, il est écrit dans les spécifications, l'idempotence est une question d'effet sur le serveur. Le premier DELETE renvoyant un 204 puis DELETE ultérieur renvoyant 404, un tel code d'état différent ne rend PAS le DELETE non idempotent. Utiliser cet argument pour justifier un retour 204 ultérieur n'est tout simplement pas pertinent.

2. OK donc il ne s'agit pas d'idempotence. Mais alors une question de suivi peut être, que se passe-t-il si nous choisissons toujours d'utiliser 204 dans DELETE ultérieur? Est-ce que c'est bon?

   Bonne question. La motivation est compréhensible: permettre au client d'atteindre le résultat souhaité, sans se soucier de la gestion des erreurs. Je dirais que renvoyer 204 dans DELETE subséquent est un "mensonge blanc" côté serveur largement inoffensif, dont le côté client ne fera pas immédiatement la différence. C'est pourquoi il y a environ 25% de personnes qui font cela dans la nature et cela fonctionne toujours. Gardez simplement à l'esprit qu'un tel mensonge peut être considéré comme sémantiquement bizarre, car GET /non-existrenvoie 404 mais DELETE /non-existdonne 204, à ce moment-là, le client comprendra que votre service n'est pas entièrement conforme à la section 6.5.4 404 Not Found .

   Mais je tiens à souligner que, la manière prévue suggérée par RFC 7231, c'est-à-dire renvoyer 404 lors de DELETE ultérieur, ne devrait pas être un problème en premier lieu. 3 fois plus de développeurs ont choisi de le faire, et avez-vous déjà entendu un incident majeur ou une plainte causée par un client incapable de gérer 404? Vraisemblablement, non, et c'est parce que tout client décent qui implémente HTTP DELETE (ou toute méthode HTTP, d'ailleurs), ne supposerait pas aveuglément que le résultat serait toujours réussi 2xx. Et puis, une fois que le développeur commence à envisager la gestion des erreurs, 404 Not Found serait l'une des premières erreurs qui viendraient à l'esprit. À ce stade, il / elle tirerait probablement une conclusion selon laquelle il est sémantiquement sûr pour une opération HTTP DELETE d'ignorer une erreur 404. Et ils l'ont fait.

Problème résolu.

Premier SUPPRIMER : 200 ou 204.

SUPPRESSIONS suivantes : 200 ou 204.

Justification : DELETE doit être idempotent. Si vous renvoyez 404 sur un deuxième SUPPRIMER, votre réponse passe d'un code de réussite à un code d'erreur . Le programme client peut prendre des actions incorrectes en fonction de l'hypothèse que la suppression a échoué.

Exemple :

• Supposons que votre opération DELETE fasse partie d'une opération en plusieurs étapes (ou d'une "saga") exécutée par le programme client.
• Le programme client peut être une application mobile effectuant une transaction bancaire, par exemple.
• Disons que le programme client a une nouvelle tentative automatique pour une opération DELETE (cela a du sens, car DELETE est supposé être idempotent).
• Disons que le premier DELETE a été exécuté avec succès, mais que la réponse 200 s'est perdue sur son chemin vers le programme client.
• Le programme client essaiera de nouveau DELETE.
• Si la deuxième tentative renvoie 404, le programme client peut annuler l'opération globale en raison de ce code d'erreur.
• Mais comme le premier DELETE exécuté avec succès sur le serveur, le système peut être laissé dans un état incohérent .
• Si la deuxième tentative renvoie 200 ou 204, le programme client continuera comme prévu.

Juste pour illustrer l'utilisation de cette approche, le guide de style de l'API HTTP pour PayPal a la directive suivante:

DELETE: Cette méthode DEVRAIT renvoyer le code d'état 204 car il n'est pas nécessaire de renvoyer de contenu dans la plupart des cas car la demande consiste à supprimer une ressource et qu'elle a été supprimée avec succès.

Comme la méthode DELETE DOIT également être idempotente, elle DEVRAIT toujours retourner 204, même si la ressource a déjà été supprimée. En général, le consommateur d'API ne se soucie pas de savoir si la ressource a été supprimée dans le cadre de cette opération ou avant. C'est aussi la raison pour laquelle 204 au lieu de 404 doivent être renvoyés.