Quels appels REST PUT / POST / DELETE doivent retourner par une convention?

153

  1. Selon l '«idéologie REST», que doit contenir le corps de la réponse pour une requête PUT / POST / DELETE?

  2. Qu'en est-il des codes de retour? Est HTTP_OKassez?

  3. Quelle est la raison de ces conventions, le cas échéant?

J'ai trouvé un bon article décrivant les différences POST / PUT: POST vs PUT Mais cela ne répond toujours pas à ma question.

rest http post http-delete tuxSlayer
la source

Réponses:

130

Pardonnez la désinvolture, mais si vous faites REST sur HTTP, la RFC7231 décrit exactement le comportement attendu de GET, PUT, POST et DELETE.

Mise à jour (3 juillet 14):
la spécification HTTP ne définit pas intentionnellement ce qui est renvoyé par POST ou DELETE. La spécification définit uniquement ce qui doit être défini. Le reste est laissé à la mise en œuvre du choix.

Darrel Miller
la source
9
@tuxslayer Je suis content que vous ne pensiez pas que j'essayais juste d'être sournois. Beaucoup de gens semblent penser que REST ajoute des exigences supplémentaires en plus des méthodes HTTP. Cependant, ce n'est pas le cas. Il existe des contraintes supplémentaires mais elles n'ont pas vraiment d'impact sur le comportement des méthodes HTTP. RFC2616 est définitivement le guide à suivre.
Darrel Miller
4
J'apprécie le lien. :) Cela m'a fait m'arrêter et réfléchir à l'outil que j'utilise. Après avoir lu votre message et le RFC, je me suis retrouvé à me référer au RFC le reste de la nuit. Cela m'a aidé à considérer le processus comme un processus HTTP d'abord, puis comme un processus de repos. Très appréciée.
Perry Tew
4
@PerryTew Vous pouvez maintenant aller ici tools.ietf.org/wg/httpbis et voir la version en cours de révision de la spécification HTTP. Prendre plaisir!
Darrel Miller
12
Peut-être ai-je juste besoin de plus de sommeil, mais je n'arrive pas à trouver les informations exactes demandées par l'OP dans la RFC. Quel devrait être le corps d'une réponse POST ou DELETE?
Cam Jackson
9
Eh bien, c'est à peu près aussi clair que la boue. Peut-être que des informations supplémentaires dans la réponse seraient utiles. Surtout quand ce lien est mort.
Doug Molineux
25

Dans l'ensemble, les conventions sont «pensez comme si vous livriez simplement des pages Web».

Pour un PUT, je retournerais la même vue que vous auriez si vous faisiez un GET immédiatement après; cela donnerait un 200 (enfin, en supposant que le rendu réussisse bien sûr). Pour un POST, je ferais une redirection vers la ressource créée (en supposant que vous faites une opération de création; sinon, renvoyez simplement les résultats); le code pour une création réussie est un 201, qui est vraiment le seul code HTTP pour une redirection qui n'est pas dans la plage 300.

Je n'ai jamais été satisfait de ce qu'un DELETE devrait renvoyer (mon code produit actuellement un HTTP 204 et un corps vide dans ce cas).

Boursiers Donal
la source
1
Faire PUTrenvoyer la demande à la page suivante semble être une mauvaise pratique, car l'actualisation de la page résultante entraînera une nouvelle exécution de la demande. Au lieu de cela, pour moi, il est logique de faire une redirection, en supposant que vous traitez des requêtes synchrones.
lobati
1
@lobati Je pense qu'il est important de noter que l'envoi de plusieurs requêtes PUT identiques devrait avoir exactement le même résultat que l'envoi d'une seule des mêmes requêtes PUT. Peut-être que la question que vous soulevez est maintenant moins importante compte tenu de ce qui précède?
Iain
3
@Iain pas vraiment. Le problème est que si quelque chose d'autre met à jour l'enregistrement plus tard, vous ne voudriez pas qu'il envoie une autre PUTdemande provoquant la restauration des données. Par exemple, si deux personnes font référence à la même page, l'une fait une mise à jour, puis l'autre fait une mise à jour, si la première personne actualise pour voir le résultat, cela finirait par faire revenir les choses avant que la deuxième personne ne soit faite leurs changements.
lobati
"Penser comme un site Web" est parfait, donc une suppression peut répondre avec quelques actions suivantes probables, qui dépendent de "l'histoire" autour de la raison pour laquelle vous supprimez une ressource. Cela pourrait au moins être un lien pour ramener l'agent vers un point de départ logique des actions, ou même une redirection vers une ressource d'état qui montre l'impact de la suppression (total de la commande) et contient d'autres liens.
Luke Puplett
3

La création d'une ressource est généralement mappée à POST, et cela doit renvoyer l'emplacement de la nouvelle ressource; par exemple, dans un échafaudage Rails, un CREATE redirigera vers le SHOW pour la ressource nouvellement créée. La même approche peut avoir un sens pour la mise à jour (PUT), mais c'est moins une convention; une mise à jour doit seulement indiquer le succès. Une suppression n'a probablement besoin que d'indiquer la réussite; si vous souhaitez rediriger, renvoyer la LISTE des ressources est probablement le plus logique.

Le succès peut être indiqué par HTTP_OK, oui.

La seule règle absolue dans ce que j'ai dit ci-dessus est qu'un CREATE doit renvoyer l'emplacement de la nouvelle ressource. Cela me semble une évidence; il est parfaitement logique que le client ait besoin de pouvoir accéder au nouvel élément.

Jacob Mattison
la source
2
Vous avez en fait mélangé PUT et POST. POST est utilisé pour créer, PUT est utilisé pour mettre à jour (et créer). Il est également intéressant de noter que PUT doit être idempotent alors que POST ne l'est pas.
Stevie
Une commande idempotente devrait fonctionner correctement quel que soit le nombre de fois que vous l'exécutez. Vous devriez donc pouvoir faire le même PUT plusieurs fois pour appliquer la même «mise à jour» sans aucun effet secondaire négatif.
Jacob Mattison
1

Selon la RFC7231, cela n'a pas d'importance et peut être vide

Comment nous implémentons la solution basée sur la norme json API dans le projet:

post / put: affiche les attributs d'objet comme dans get (le filtre de champ / les relations s'appliquent de la même manière)

supprimer: les données ne contiennent que null (pour sa représentation d'un objet manquant)

état de la suppression standard: 200

Marius Gri
la source
0

J'aime Alfonso Tienda réponse du code d'état HTTP pour la mise à jour et la suppression?

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 l' opération réussie , vous pouvez donc renvoyer 204 , mais il est vrai que idempotent n'implique pas nécessairement la même réponse)

Autres erreurs:

  • 400 Mauvaise requête (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 Un 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 DELETE 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 malformée ou mauvaise requête plus courante qu'en cas DELETE).

  • 401 Non autorisé

  • 403 Interdit : échec d'authentification ou ID d'application non valide.

  • 405 Non autorisé . Sûr.

  • 409 Un conflit de ressources peut être possible dans des systèmes complexes, comme dans DELETE.

  • 422 Entité non traitable Permet de faire la distinction entre une "demande incorrecte" (par exemple, XML / JSON mal formé) et des valeurs de champ invalides

  • Et 501 , 502 en cas d'erreurs.

Ryabchenko Alexander
la source