Quels appels REST PUT / POST / DELETE devraient-ils revenir par une convention?
Selon "l'idéologie REST", que devrait-il figurer dans le corps de la réponse pour les demandes PUT/POST/DELETE?
Qu'en est-il des codes de retour? Est
HTTP_OKsuffisant?Quelle est la raison de telles 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.
Pardonnez la légèreté, mais si vous faites REST sur HTTP alors RFC7231 décrit exactement quel comportement est attendu de GET, PUT, POST = et DELETE.
Mise à jour (3 juillet 2014):
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é à l'implémenteur de choisir.
Dans l’ensemble, les conventions sont les suivantes: "pensez à ne livrer que des pages Web".
Pour un PUT, je reviendrais sur le même point de vue que si vous réalisiez une opération 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 réalisiez 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 en réalité le seul code HTTP pour une redirection qui ne se situe 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).
La création d'une ressource est généralement mappée sur POST, ce qui devrait renvoyer l'emplacement de la nouvelle ressource. par exemple, dans un Rails échafaud, un CREATE sera redirigé 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 Il suffit probablement d’indiquer le succès d’une suppression. Si vous souhaitez rediriger des données, le renvoi de la liste des ressources a probablement tout son sens.
Le succès peut être indiqué par HTTP_OK, oui.
La seule règle absolue de 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 doit pouvoir accéder au nouvel élément.
Par la RFC7231 ce n'est pas grave et peut être vide
Comment nous implémentons la solution standard JSON Api dans le projet:
post/put: sortie des attributs d'objet comme dans get (le champ filter/relations s'applique de la même manière)
delete: les données ne contiennent que null (car c'est une représentation de l'objet manquant)
statut pour la suppression standard: 200