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)?

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".

METTRE

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.

SUPPRIMER

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

Source: Liste des codes d'état HTTP: succès 2xx

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).

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

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.

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