161 votes

Quels appels REST PUT/POST/DELETE doivent être retournés par convention ?

  1. Selon l'"idéologie REST", que doit contenir le corps de réponse d'une demande PUT/POST/DELETE ?

  2. Qu'en est-il des codes de retour ? Est-ce que HTTP_OK assez ?

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

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

134voto

Darrel Miller Points 56797

Pardonnez ma désinvolture, mais si vous utilisez REST via HTTP, alors RFC7231 décrit exactement le comportement attendu de GET, PUT, POST et DELETE.

26voto

Donal Fellows Points 56559

Dans l'ensemble, les conventions sont "pensez comme si vous livriez des pages web".

Pour un PUT, je renverrais la même vue que celle que vous obtiendriez si vous faisiez un GET immédiatement après ; cela donnerait un 200 (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 effectuez 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 gamme 300.

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

3voto

Jacob Mattison Points 32137

La création d'une ressource est généralement associée au POST, qui doit renvoyer l'emplacement de la nouvelle ressource ; par exemple, dans un échafaudage Rails, un CREATE redirigera vers le SHOW de la ressource nouvellement créée. La même approche pourrait s'appliquer à la mise à jour (PUT), mais c'est moins conventionnel ; une mise à jour doit seulement indiquer le succès. Un delete n'a probablement besoin que d'indiquer le succès aussi ; si vous voulez rediriger, retourner la LIST des ressources a probablement plus de sens.

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 retourner l'emplacement de la nouvelle ressource. Cela me semble être une évidence ; il est parfaitement logique que le client doive être en mesure d'accéder au nouvel élément.

Prograide.com

Prograide est une communauté de développeurs qui cherche à élargir la connaissance de la programmation au-delà de l'anglais.
Pour cela nous avons les plus grands doutes résolus en français et vous pouvez aussi poser vos propres questions ou résoudre celles des autres.

Powered by:

X