Quel code d'état dois-je définir pour UPDATE( PUT) et DELETE(par exemple, le produit a été mis à jour avec succès)?
Code d'état HTTP pour la mise à jour et la suppression?
Réponses:
Pour une demande PUT : HTTP 200 ou HTTP 204 devrait impliquer une "mise à jour réussie de la ressource".
Pour une demande DELETE : HTTP 200 ou HTTP 204 devrait impliquer "ressource supprimée avec succès". HTTP 202 peut également être renvoyé, ce qui impliquerait que l'instruction a été acceptée par le serveur et que la "ressource a été marquée pour suppression".
Si une ressource existante est modifiée, les codes de réponse 200 (OK) ou 204 (Pas de contenu)> DEVRAIENT être envoyés pour indiquer la réussite de la demande.
Une réponse réussie DEVRAIT être 200 (OK) si la réponse comprend une entité décrivant le statut, 202 (Accepté) si l'action n'a pas encore été exécutée, ou 204 (Pas de contenu) si l'action a été exécutée mais la réponse ne comprend pas une entité.
Source: W3.org: Définitions des méthodes HTTP / 1.1
HTTP 200 OK: réponse standard pour les requêtes HTTP réussies. La réponse réelle dépendra de la méthode de demande utilisée.
HTTP 204 Pas de contenu: le serveur a traité la demande avec succès, mais ne renvoie aucun contenu
40
Poste très utile! Cependant, je me demande quel devrait être le code d'état HTTP si la demande envoyée par le client est valide (SUPPRIMER monSite / entité / 123 ) et l'entité à supprimer n'existe pas.
—
Martin
@Martin: Dans ce cas, le service doit renvoyer un HTTP 404. À proprement parler, une demande DELETE ou GET pour une ressource qui n'existe pas n'est pas une demande "valide" - c'est-à-dire. le client ne doit pas réessayer cette demande car elle ne réussira jamais ... Le protocole HTTP définit 2 catégories de problèmes - ceux avec un code d'état 4xx, où le client doit modifier la demande avant de la réessayer, et ceux avec un état 5xx code, qui indique que le service a rencontré des problèmes et que le client doit / pourrait réessayer la même demande exacte sans la modifier.
—
Daniel Vassallo
@JeffMartin Cela peut être le cas du point de vue de l'utilisateur, mais en ce qui concerne le serveur, si la ressource n'existe pas, le serveur doit renvoyer 404.
—
Randolpho
@Randolpho, Idempotence consiste à obtenir le même résultat, que vous appeliez une opération une ou plusieurs fois. Le client vous demande de vous assurer que la ressource est supprimée. Quel est l'avantage de retourner 404? Pourquoi a-t-il besoin de savoir de toute façon? Maintenant, la logique client doit gérer deux codes de réponse distincts au lieu d'un.
—
Gili
@Gili: le wiki expliquera peut-être mieux: les méthodes PUT et DELETE sont définies pour être idempotentes ... notez que l'idempotence se réfère à l'état du système une fois la requête terminée, donc pendant que le serveur prend des mesures (par exemple, supprimer un enregistrement) ) ou le code de réponse qu'il renvoie peut être différent lors des requêtes suivantes, l'état du système sera le même à chaque fois.
—
Randolpho
Réponse courte: pour PUT et DELETE, vous devez envoyer 200 (OK) ou 204 (sans contenu).
Réponse longue: voici un diagramme de décision complet (cliquez pour agrandir).
Le diagramme est étonnant. Existe-t-il une version à plus haute résolution pour l'impression?
—
KiKi
Dans le contexte du POST d'une ressource existante, une autre discussion SO ( stackoverflow.com/questions/3825990/… ) suggère d'envoyer 409 Conflict ou 302 Found au lieu d'ajouter le contenu.
—
koppor
Je suis curieux de savoir si les réponses 204 et 200 après une suppression doivent être inversées et si elles sont correctes telles quelles, pourquoi? Supprimé? -> La réponse inclut une entité? -> oui -> 204 Pas de contenu; non -> 200 OK
—
mat
La version mise à jour de l'image est ici: raw.github.com/for-GET/http-decision-diagram/master/httpdd.png
—
zaius
Il manque PATCH.
—
doremi
Voici quelques conseils:
SUPPRIMER
200 (si vous souhaitez envoyer des données supplémentaires dans la réponse) ou 204 (recommandé).
202 L'opération supprimée n'a pas encore été validée.
S'il n'y a rien à supprimer, utilisez 204 ou 404 (l'opération DELETE est idempotente, la suppression d'un élément déjà supprimé est une opération réussie , vous pouvez donc retourner 204 , mais il est vrai que idempotent n'implique pas nécessairement la même réponse)
Autres erreurs:
- 400 Bad Request (Une syntaxe mal formée ou une mauvaise requête est étrange mais possible).
- 401 Échec de l'authentification non autorisée
- 403 Interdit : Échec de l'autorisation ou ID d'application non valide.
- 405 non autorisé . Sûr.
- 409 Les conflits de ressources peuvent être possibles dans des systèmes complexes.
- Et 501 , 502 en cas d'erreurs.
METTRE
Si vous mettez à jour un élément d'une collection
- 200/204 avec les mêmes raisons que SUPPRIMER ci-dessus.
- 202 si l'opération n'a pas encore été validée.
L'élément référencé n'existe pas:
- PUT peut être 201 (si vous avez créé l'élément parce que c'est votre comportement)
404 Si vous ne souhaitez pas créer d'éléments via PUT.
400 Bad Request (syntaxe incorrecte ou mauvaise requête plus courante qu'en cas de suppression).
- 401 non autorisé
- 403 Interdit : échec d'authentification ou ID d'application non valide.
- 405 non autorisé . Sûr.
- 409 Les conflits de ressources peuvent être possibles dans des systèmes complexes, comme dans DELETE.
- 422 Entité non traitable Elle permet de faire la distinction entre une "demande incorrecte" (par exemple XML / JSON mal formé) et des valeurs de champ non valides
- Et 501 , 502 en cas d'erreurs.
Cette réponse est composée presque entièrement de deux grandes citations, mais il n'y a pas d'attribution. D'où citez-vous?
—
Quentin
204 est-il un état approprié pour retourner pour une demande PUT, si l'état n'est pas changé efficacement? Par exemple, vous demandez de désactiver un utilisateur mais l'utilisateur est déjà inactif.
—
Ε Г И І И О
La demande PUT est idempotente, vous pouvez donc retourner un 204, car l'objet a changé dans le système. PUT n'est pas PATCH, vous n'êtes donc pas sûr du champ que vous souhaitez modifier. Vous pouvez renvoyer un 501 - 502, si votre conception a besoin de savoir si l'objet était exactement le même que l'objet dans la demande mais ... je ne l'aime pas vraiment .. je préfère 204 ou, si vous voulez désactiver un utilisateur, sans changer plus de champs, vous pouvez peut-être utiliser PATCH.
—
Alfonso Tienda
J'ajouterais une entité non traitable HTTP 422. Il permet de faire la distinction entre une "demande incorrecte" (par exemple XML / JSON mal formé) et des valeurs de champ non valides.
—
vdboor
La RFC 2616 décrit les codes d'état à utiliser .
Et non, ce n'est pas toujours 200.
En plus de 200 et 204, 205 (Réinitialiser le contenu) pourrait être une réponse valide.
Le serveur a satisfait la demande et l'agent utilisateur DEVRAIT réinitialiser la vue du document qui a provoqué l'envoi de la demande ... [par exemple] effacement du formulaire dans lequel l'entrée est donnée.
Étant donné que la question se pose de savoir si SUPPRIMER "devrait" retourner 200 contre 204, il convient de considérer que certaines personnes recommandent de renvoyer une entité avec des liens, la préférence est donc pour 200 .
"Au lieu de renvoyer 204 (sans contenu), l'API devrait être utile et suggérer des endroits où aller. Dans cet exemple, je pense qu'un lien évident à fournir est de" 'quelque part.com/conteneur /' (moins 'ressource') "- le conteneur duquel le client vient de supprimer une ressource. Le client souhaite peut-être supprimer plus de ressources, ce serait donc un lien utile. "
http://blog.ploeh.dk/2013/04/30/rest-lesson-learned-avoid-204-responses/
Si un client rencontre une réponse 204, il peut soit abandonner, aller au point d'entrée de l'API, soit revenir à la ressource précédente qu'il a visitée. Aucune des deux options n'est particulièrement bonne.
Personnellement, je ne dirais pas que 204 est faux (l'auteur non plus, il dit "ennuyeux") car une bonne mise en cache côté client présente de nombreux avantages. Le mieux est d'être cohérent dans les deux cas.
Voici un code d'état, que vous devez connaître pour votre type de connaissances.
Réponses d'information 1XX
- 100 Continuer
- 101 Changer de protocole
- 102 Traitement
- 103 premiers indices
2XX Success
- 200 OK
- 201 créé
- 202 Accepté
- 203 Informations sans autorité
- 204 Aucun contenu
- 205 Réinitialiser le contenu
- 206 Contenu partiel
- 207 Multi-Status
- 208 déjà signalé
- 226 IM d'occasion
Redirection 3XX
- 300 choix multiples
- 301 déplacé de façon permanente
- 302 trouvés
- 303 Voir les autres
- 304 non modifié
- 305 Utiliser un proxy
- 306 Switch Proxy
- 307 Redirection temporaire
- 308 Redirection permanente
Erreurs du client 4XX
- 400 Mauvaise demande
- 401 non autorisé
- 402 Paiement requis
- 403 Interdit
- 404 introuvable
- 405 Méthode non autorisée
- 406 Non acceptable
- 407 Authentification proxy requise
- 408 Délai de demande
- 409 Conflit
- 410 disparu
- 411 Longueur requise
- 412 Échec de la condition préalable
- 413 Charge utile trop importante
- 414 URI trop long
- 415 Type de support non pris en charge
- 416 Portée insatisfaisante
- 417 Attente a échoué
- 418 je suis une théière
- 420 Échec de la méthode
- 421 Demande mal acheminée
- 422 Entité non traitable
- 423 verrouillé
- 424 Dépendance défaillante
- 426 Mise à niveau requise
- 428 Condition préalable requise
- 429 Trop de demandes
- 431 Champs d'en-tête de demande trop grands
- 451 non disponible pour des raisons juridiques
Erreurs du serveur 5XX
- 500 Erreur de serveur interne
- 501 non implémenté
- 502 Bad Gateway
- 503 Service non disponible
- 504 expiration de la passerelle
- 505 Version Http non prise en charge
- 506 Varient Négocier également
- 507 Stockage insuffisant
- 508 boucle détectée
- 510 non étendu
- 511 Authentification réseau requise
En juin 2014, le RFC7231 rend le RFC2616 obsolète. Si vous effectuez REST sur HTTP, le RFC7231 décrit exactement le comportement attendu de GET, PUT, POST et DELETE
Lorsqu'une ressource est modifiée, le code de réponse doit être 200 («OK») . Si l'état de la ressource change d'une manière qui modifie l'URI de la ressource (par exemple, un compte d'utilisateur est renommé), le code de réponse est 301 («Déplacé en permanence») et l'en-tête Location doit fournir le nouvel URI.
Lorsqu'un objet est supprimé, le code de réponse doit être 200 («OK»).
Suivez le lien ci-dessous pour plus de détails - code d'état pour le repos