Question Code d'état HTTP pour la mise à jour et la suppression?


Quel code d'état dois-je définir pour UPDATE (PUT) et DELETE (par exemple, le produit a été mis à jour avec succès)?


992
2018-02-26 15:16


origine


Réponses:


Pour un METTRE demande: HTTP 200 ou HTTP 204 devrait impliquer "ressource mise à jour avec succès".

Pour un EFFACER demande: 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".

9.6 PUT

Si une ressource existante est modifiée, les codes de réponse 200 (OK) ou 204 (sans contenu)> DEVRAIENT être envoyés pour indiquer que la demande a été traitée avec succès.

9.7 SUPPRIMER

Une réponse réussie DEVRAIT être 200 (OK) si la réponse inclut une entité décrivant le statut, 202 (Acceptée) 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é.

La source: w3.org: Définitions de méthodes HTTP / 1.1

HTTP 200 OK: Réponse standard pour un HTTP réussi   demandes La réponse réelle sera   dépend de la méthode de requête utilisée.

HTTP 204 Pas de contenu: Le serveur a traité la demande avec succès, mais ne renvoie aucun contenu

La source: Liste des codes d'état HTTP: 2xx Success


1543
2018-02-26 15:18



Réponse courte: pour PUT et DELETE, vous devez envoyer 200 (OK) ou 204 (pas de contenu).

Réponse longue: voici un diagramme de décision complet (cliquez pour agrandir).

HTTP 1.1 decision diagram

La source: https://github.com/for-GET/http-decision-diagram


717
2018-02-26 15:23



Voici quelques conseils:

EFFACER

  • 200 (si vous voulez envoyer des données supplémentaires dans la réponse) ou 204 (conseillé).

  • 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, supprimer un élément déjà supprimé est Opération réussie, donc vous pouvez revenir 204, mais il est vrai que idempotent n'implique pas nécessairement la même réponse)

D'autres erreurs:

  • 400  Mauvaise Demande (La syntaxe mal formée ou une mauvaise requête est étrange mais possible).
  • 401  Non autorisé Échec d'authentification
  • 403  Interdit: Échec d'autorisation ou ID d'application non valide.
  • 405  Interdit. Sûr.
  • 409  Conflit de ressources peut être possible 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 voulez pas créer d'éléments via PUT.

  • 400  Mauvaise Demande (Syntaxe malformée ou une mauvaise requête plus commune que dans le cas de DELETE).

  • 401  Non autorisé 
  • 403  Interdit: Échec d'authentification ou ID d'application non valide
  • 405  Interdit. Sûr.
  • 409  Conflit de ressources peut être possible dans des systèmes complexes, comme dans DELETE.
  • 422  Entité non traitable Il aide à distinguer entre une "mauvaise requête" (par exemple XML / JSON malformé) et des valeurs de champs invalides
  • Et 501, 502 en cas d'erreurs

105
2017-09-24 12:14



La RFC 2616 décrit quels codes d'état utiliser.

Et non, c'est ne pas toujours 200.


13
2018-02-26 15:20



En plus des 200 et 204, 205 (réinitialiser le contenu) pourrait être une réponse valide.

Le serveur a rempli la demande et l'agent utilisateur DEVRAIT réinitialiser la vue de document qui a provoqué l'envoi de la demande ... [par exemple] l'effacement du formulaire dans lequel l'entrée est donnée.


7
2018-01-08 21:15



Depuis la question se penche sur si EFFACER "devrait" retourner 200 contre 204 il est utile de considérer que certaines personnes recommandent de renvoyer une entité avec des liens de sorte que la préférence est pour 200.

"Au lieu de retourner 204 (pas de 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 " 'somewhere.com/container/' (moins la 'ressource') "- le récipient duquel   le client vient de supprimer une ressource. Peut-être que le client souhaite   supprimer plus de ressources, ce qui serait 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 à   le point d'entrée de l'API, ou revenir à la ressource précédente, il   a visité. Aucune des deux options n'est particulièrement bonne.

Personnellement, je ne dirais pas que 204 est faux (ni l'auteur, il dit "ennuyeux") parce qu'une bonne mise en cache du côté client présente de nombreux avantages. Le mieux est d'être cohérent de toute façon.


6
2018-05-29 02:02



En Juin 2014 RFC7231 obsolète RFC2616. Si vous faites REST sur HTTP alors RFC7231 décrit exactement le comportement attendu de GET, PUT, POST et DELETE


2
2017-11-22 15:52