La suppression d'une ressource à l'aide de http SUPPRIMER

Donc, étant donné que la SUPPRESSION des verbes en Http est la quantité, lorsque j'ai problème de la demande, ce qui devrait arriver la deuxième (ou troisième, ou quatrième, etc...)?

DELETE /person/123

La première fois, la ressource est supprimée et je retourne a 204 (bon, pas le contenu). Dois-je retourner un 204 lors des appels ultérieurs ou une erreur 404 (page non trouvée)?

InformationsquelleAutor Craig Wilson | 2011-06-22
  1. 126

    Que les requêtes HTTP dans un apatride système doit être indépendant, les résultats d'une requête ne devrait pas être tributaire d'une demande antérieure. Envisager ce qui se passerait si deux utilisateurs ont fait un DELETE sur la même ressource simultanément. Il fait sens pour la deuxième demande pour obtenir un 404. La même chose devrait être vraie si un utilisateur fait deux demandes.

    Je suppose que le fait d'avoir SUPPRIMER retour deux réponses différentes ne se sent pas équipotent à vous. Je trouve qu'il est utile de penser à la quantité de demandes que de laisser le système dans le même état, pas nécessairement avoir la même réponse. Donc, indépendamment de savoir si vous SUPPRIMEZ une ressource existante, ou d'une tentative de SUPPRESSION d'une ressource qui n'existe pas, le serveur de ressources de l'état est le même.

    • Je vous remercie. Cela fait donc beaucoup de sens. J'ai été en effet la pensée de la quantité que le retour par le même type de réponse.
    • Attention! Dans le livre, Subbu totalement en contradiction avec ce que je viens de dire. Il dit idempotence signifie qu'il doit retourner la même réponse. Heureusement, Subbu va être à RESTFest donc, je vais clarifier avec lui.
    • Eh bien, il fait sens pour moi et est en conformité avec ce que j'ai d'abord pensée en ce qui concerne ce que l'idempotence signifiait. Pensez au moment où Un utilisateur émet une requête GET pour le point 1, B l'utilisateur émet une requête POST que les mises à jour de la rubrique 1, et Un utilisateur émet une requête GET pour le point 1 de nouveau. l'utilisateur A obtenir des réponses différentes. Cela m'indique que la réponse n'a rien à voir avec l'idempotence.
    • Je suis d'accord qu'il ne se sent pas idempotent pour avoir 2 réponses différentes à la même demande. Je me sens comme une demande de SUPPRESSION est plus le long des lignes de "assurez-vous que cette ressource est supprimée". Si c'est déjà supprimés ou supprimés par la demande ne change pas le résultat de la requête, "OK", le serveur répond, la ressource n'est pas là.
    • Si vous SUPPRIMEZ quelque chose qui n'existe pas, il suffit de retourner une 204 (même si la ressource n'a jamais existé). Le client voulait la ressource disparu et il est parti. Retourner une erreur 404 est d'exposer le traitement interne qui est sans importance pour le client et le résultat sera inutile condition d'erreur.
    • c'est une approche intéressante. Personnellement, je voudrais une sorte de confirmation que j'ai utilisé le bon Uri. Avec une 204 pour. Tout ce que je n'ai aucune idée de si le serveur fait ce que je voulais ou pas.
    • Je ne suis pas sûr que j'ai suivi votre argument. Le code de statut ne vous dit pas quelle ressource vous êtes à la suppression (c'est dans l'URI). Si vous obtenez une réponse 404, cela veut dire que tu doit modifier l'URI et essayer de nouveau? Il semble que 204 dirais que le bon URI a été utilisé.
    • Vous avez dit retour 204, même si la ressource n'a jamais existé. Si la ressource n'a jamais existé, je pense que je ferais comme le client de savoir qu'il a juste essayé de supprimer quelque chose qui n'a jamais existé. De toute façon, comme Julian mentionne dans sa réponse, HTTP ne se soucie pas, faire ce qui fonctionne pour vous.
    • Je suppose que le concept clé ici est que vous ne devriez pas utiliser SUPPRIMER pour vérifier si la ressource existe, vous seriez la première utilisation pour OBTENIR que. Ensuite, si la réponse est 200, vous souhaitez SUPPRIMER, sinon même pas la peine de le faire. Je pense donc qu'il est judicieux de toujours retourner une 204 sur SUPPRIMER.
    • Si vous souhaitez vérifier l'existence d'une ressource d'un CHEF de demande peut même être un moyen moins coûteux à aller.
    • avez-vous demander à Subbu de retour en 2011 ? 🙂
    • Si une deuxième tentative retourne 404, il y a un risque de débordements sur le client. J'ai ajouté une réponse à expliquer cette possibilité. Donc, le mieux est de retour 200 (ou 204) sur les requêtes de SUPPRESSION.
    • Le RFC dit que c'est censé se comporter comme rm. rm renvoie une erreur si elle n'existe pas. tools.ietf.org/html/rfc7231#section-4.3.5
    • Peut-on faire SUPPRIMER un retour 204 tout le temps ? Ensuite, pour confirmer que votre SUPPRIMER travaillé, vous essayez d'OBTENIR. Est-ce qu'on doit mettre en œuvre les SUPPRIMER ?

    InformationsquelleAutor Darrel Miller
  2. 28

    Les services web RESTful livre de cuisine est une grande ressource pour le présent. Par chance, son google preview afficher la page sur SUPPRIMER (page 11):

    La méthode DELETE est idempotent. Cette
    implique que le serveur doit retourner
    code de réponse 200 (OK), même si le
    serveur supprimé la ressource dans un
    demande précédente. Mais dans la pratique,
    la mise en œuvre de SUPPRIMER un idempotent
    l'opération nécessite que le serveur garder
    le suivi de toutes les ressources supprimées.
    Sinon, il peut renvoyer une erreur 404 (Pas
    Trouvé).

    • Oui, cela ressemble à une grande ressource. Toutefois, la SUPPRESSION de l'article n'est pas en tirant vers le haut pour moi (c'est la page 23 et l'aperçu a rédigé). Avez-vous lu ce livre? Savez-vous la réponse à ma question?
    • Ce livre est un must pour la construction de REPOS (il parle en particulier, pas dans une langue).
    • La lecture du livre de cuisine, il est dit que vous DEVEZ retourner à 200 OK, même si vous avez supprimé déjà. Cependant, dans la pratique, que nécessiterait le serveur de suivre toutes les ressources supprimées, par conséquent, vous POUVEZ utiliser 404. Il va de soi que les problèmes de sécurité peuvent vous obliger à toujours revenir 404. La Page 11.
    • +1 Seconde et recommande fortement le livre pour la conception de services RESTful.
    • Génial merci, j'ai manqué à la page 11. Je vais certainement acheter le livre.
    • Eh bien, le livre est mauvais. Idempotence ne signifie pas que le code de statut sera le même. Ce qui est pertinent, c'est l'état final du serveur.

    InformationsquelleAutor yves amsellem
  3. 9

    D'abord SUPPRIMER: 200 ou 204.

    Ultérieure Supprime: 200 ou 204.

    Justification: SUPPRIMER doit être idempotent. Si vous retournez 404 sur un deuxième SUPPRIMER, votre réponse est en train de changer à partir d'un code de réussite à un code d'erreur. Le programme client peut prendre incorrect des actions basées sur l'hypothèse de la SUPPRESSION a échoué.

    Exemple:

    • Supposons que votre opération de SUPPRESSION est partie d'un multi-étape de l'opération (ou une "saga") exécuté par le programme client.
    • Le programme client peut être une application mobile de l'exécution d'une opération de banque, par exemple.
    • Disons que le programme client est une relance automatique pour une opération de SUPPRESSION (c'est logique, car SUPPRIMER est censé être idempotent).
    • Disons-le d'abord de SUPPRIMER a été exécuté avec succès, mais la réponse de 200 s'est perdu sur son chemin vers le programme client.
    • Le programme client va réessayer de le SUPPRIMER.
    • Si la deuxième tentative retourne 404, le programme client peut annuler l'ensemble de l'opération en raison de ce code d'erreur.
    • Mais parce que la première SUPPRIMER exécutée 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 pourra se dérouler comme prévu.
    • La question est, ce qui est important pour le client, que le il supprimé la ressource, ou que la ressource a été supprimé. Que faire si un autre client supprimé la ressource au cours de la saga. Voulez-vous vraiment à l'échec compte tenu de la clients objectif a été atteint?
    • Bon point. Ce qui est plus important repose sur le contexte de l'entreprise. Mais en général, je préfère retourner 204 sur une deuxième tentative de SUPPRIMER, même si la ressource a été supprimé par un autre client. Je ne veux pas l'échec du service (c'est à dire, 404) étant donné que les clients de l'objectif a été atteint.
    • Comme d'autres l'ont mentionné, idempotence est pas ce que votre code de réponse est, c'est ce que votre état du serveur est.
    • Je suis d'accord idempotence est sur le serveur de l'état, mais d'une autre réponse code peut conduire le client à changer l'état du serveur inutilement par l'annulation d'une saga en cours.
    • Merson, ce code va vous retourner si le client demande la suppression d'un élément qui n'a JAMAIS existé ? 204 ? ou 404 ? Si vous retournez toujours 204 quel est le point dans la vérification de code de retour ?
    • Si vous avez un moyen de savoir que l'élément n'a jamais existé, vous devez retourner 404 dans la première et subsequente SUPPRIMER tentatives. Si vous ne le faites pas, mais le programme client a besoin de savoir si l'élément existe, vous pouvez avoir le programme client de toujours faire un GET avant de le SUPPRIMER. OBTENEZ de retour 404 si l'élément n'existe pas (parce qu'il n'a jamais existé ou qu'il a été supprimé).

    InformationsquelleAutor Paulo Merson