REST DELETE est-il vraiment idempotent?

DELETE est censé être idempotent.

Si je supprime http://example.com/account/123, cela va supprimer le compte.

Si je le refais, est-ce que je m’attendrais à un 404, puisque le compte n’existe plus? Et si j’essaie de SUPPRIMER un compte qui n’a jamais existé?

Idempotence fait référence à l’état du système une fois la requête terminée

Dans tous les cas (hormis les problèmes d’erreur – voir ci-dessous), le compte n’existe plus.

D’ ici

“Les méthodes peuvent aussi avoir la propriété” idempotence “dans la mesure où ( hormis les erreurs ou les problèmes d’expiration ) les effets secondaires de N> 0 requêtes identiques sont les mêmes que pour une requête unique. Les méthodes GET, HEAD, PUT et DELETE partagent Cette propriété. De même, les méthodes OPTIONS et TRACE NE DOIVENT PAS avoir d’effets secondaires, et sont donc insortingnsèquement idempotentes. ”

Le bit clé avec les effets secondaires de N> 0 requêtes identiques est le même que pour une requête unique.

Vous auriez raison de vous attendre à ce que le code d’état soit différent, mais cela n’affecte pas le concept de base d’idempotency – vous pouvez envoyer la demande plus d’une fois sans apporter de modifications supplémentaires à l’état du serveur.

Idempotent concerne l’effet de la demande et non le code de réponse que vous obtenez.

http://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html#sec9.1.2 dit:

Les méthodes peuvent également avoir la propriété “idempotence” dans la mesure où (hormis les problèmes d’erreur ou d’expiration) les effets secondaires de N> 0 requêtes identiques sont les mêmes que pour une requête unique.

Bien que vous puissiez obtenir un code de réponse différent, l’ effet de l’envoi de N + 1 DELETE à la même ressource peut être considéré comme identique.

Depuis la RFC HTTP :

Les méthodes peuvent également avoir la propriété “idempotence” dans la mesure où (hormis les problèmes d’erreur ou d’expiration) les effets secondaires de N> 0 requêtes identiques sont les mêmes que pour une requête unique.

Notez que “effets secondaires”, pas “réponse”.

La distinction importante est que idempotent se réfère aux effets secondaires , pas tous les effets ou les réponses. Si vous faites un DELETE http://example.com/account/123 l’effet est que le compte 123 est maintenant supprimé du serveur. C’est le seul et unique effet, le seul et unique changement à l’état du serveur. Maintenant, disons que vous faites la même demande DELETE http://example.com/account/123 nouveau, le serveur répondra différemment, mais son état est le même.

Ce n’est pas comme la demande DELETE a décidé de changer l’état du serveur d’une manière différente car le compte était manquant, tel que la suppression d’un autre compte ou de laisser un journal des erreurs. Non, vous pouvez appeler la même demande DELETE un million de fois et vous pouvez être sûr que le serveur est dans le même état que lorsque vous l’avez appelé pour la première fois .

Je pense la même chose, 404 – Le compte n’existe pas.

Vous pourriez discuter 400 – Bad Request. Mais dans le sens de REST, l’object sur lequel vous avez demandé d’effectuer une action n’existe pas. Cela se traduit par 404.

Oui. Indépendamment du code de réponse.

Depuis la dernière version de RFC pour HTTP 1.1 (emphase sur la mienne):

Les méthodes Idempotent se distinguent parce que la demande peut être répétée automatiquement si un échec de communication se produit avant que le client puisse lire la réponse du serveur. Par exemple, si un client envoie une demande PUT et que la connexion sous-jacente est fermée avant la réception d’une réponse, le client peut établir une nouvelle connexion et réessayer la demande idempotent. Il sait que la répétition de la demande aura le même effet, même si la demande d’origine a réussi, bien que la réponse puisse être différente.

Il dit explicitement que la réponse peut différer. Plus important encore, cela indique la raison du concept: si une action est idempotente, le client peut répéter l’action quand il rencontre une erreur et sait que cela ne causera pas de plantage; Dans le cas contraire, le client devra faire une requête supplémentaire (éventuellement GET ) pour voir si le précédent est efficace, avant de répéter l’action en toute sécurité. Tant que le serveur peut faire une telle garantie, l’action est idempotente. Citation d’ un autre commentaire :

Calculer l’idempotence concerne la robustesse d’un système. Comme les choses peuvent échouer (p. Ex. Panne de réseau), quand une panne est détectée, comment récupérez-vous? La récupération la plus facile consiste simplement à recommencer, mais cela ne fonctionne que si cela est à nouveau idempotent. Par exemple, la discard(x) est idempotente, mais pop() ne l’est pas. Tout est question de récupération d’erreur.