web-dev-qa-db-fra.com

RESTful - Que doit contenir un corps de réponse DELETE

Disons que j'ai une API où vous pouvez obtenir des utilisateurs:

GET /RESTAPI/user/

Et vous pouvez supprimer des utilisateurs en:

DELETE /RESTAPI/user/123

Quelle est la convention RESTful sur ce que le corps de réponse de DELETE doit contenir? Je m'attendais à ce que ce soit la nouvelle liste de tous les utilisateurs qui ne contient plus l'utilisateur avec l'ID 123.

La recherche sur Google ne m'a pas donné de réponses satisfaisantes. Je n'ai trouvé que des opinions sur la façon de procéder, mais n'y a-t-il pas une définition stricte des services RESTful ?

Ce n'est PAS un doublon de Que doit renvoyer une API RESTful POST/DELETE dans le corps? et Que REST PUT/POST/DELETE doit renvoyer) par une convention? puisque cette question demande une définition stricte concernant DELETE. Ces questions n'ont été répondues que par des opinions vagues.

resthttprestful-url
40
tmuecksch

La raison pour laquelle vous n'obtenez pas de réponses dures est qu'il n'y a pas de norme RESTful dure. Je ne peux donc que vous suggérer de créer un standard dur et de vous y tenir dans vos propres API

Je l'ai utilisé comme guide pour les services RESTful http://www.vinaysahni.com/best-practices-for-a-pragmatic-restful-api

Il dit répondre avec un statut 204 et un corps vide

Je m'en tiens à ces normes et les documente bien pour quiconque souhaite utiliser mes API

44
Leon

204 No Content est une réponse populaire pour DELETE et parfois PUT également.

Cependant, si vous implémentez HATEOAS, le renvoi d'un 200 OK avec des liens à suivre peut être plus idéal. En effet, une API HATEOAS REST fournit le contexte au client. Pensez à l'emplacement vers lequel une application utilisateur navigue après avoir émis avec succès une commande de suppression. Voici un bref article avec plus de discussion à ce sujet. Voir l'article du blog pour une discussion plus complète.

Évitez 204 réponses si vous créez une application HATEOAS.

Ceci est une leçon sur la conception de l'API REST que j'ai apprise lors de la construction des API non triviales REST. Afin d'être aussi favorable que possible au client, un REST ne doit pas renvoyer 204 réponses (sans contenu).

Du point de vue du service, une réponse 204 (sans contenu) peut être une réponse parfaitement valide à une demande POST, PUT ou DELETE. En particulier, pour une demande DELETE, cela semble très approprié, car que pouvez-vous dire d'autre?

Cependant, du point de vue d'un client adapté à HATEOAS, une réponse 204 est problématique car il n'y a aucun lien à suivre. Lorsque l'hypermédia agit comme le moteur de l'état de l'application, lorsqu'il n'y a pas de liens, il n'y a pas d'état. En d'autres termes, une réponse 204 supprime tout état d'application.

Cet article couvre POST, PUT, DELETE et GET. Voici la discussion spécifique sur DELETE:

Répondre aux demandes DELETE

Une demande DELETE représente l'intention de supprimer une ressource. Ainsi, si le service gère avec succès une demande DELETE, que peut-il faire d'autre que de renvoyer un 204 (No Content)? Après tout, la ressource vient d'être supprimée.

Une ressource est souvent membre d'une collection, ou autrement "détenue" par un conteneur. Par exemple, http://foo.ploeh.dk/api/tags/rock représente une balise "rock", mais une autre façon de voir les choses est que la ressource/rock est contenue dans le conteneur de balises (qui est lui-même une ressource). Cela devrait être familier aux utilisateurs de Atom Pub.

Imaginez que vous souhaitez supprimer la ressource http://foo.ploeh.dk/api/tags/rock . Pour atteindre cet objectif, vous émettez une demande DELETE à son encontre. Si tout ce que votre client récupère est un 204 (sans contenu), il vient de perdre son contexte. Où va-t-il à partir de là? Sauf si vous gardez l'état du client, vous ne savez pas d'où vous venez.

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 http://foo.ploeh.dk/api/tags - le conteneur dont le client vient de supprimer une ressource. Peut-être que le client souhaite supprimer plus de ressources, ce serait donc un lien utile.

9
Grokify

Quelle est la convention RESTful sur ce que le corps de réponse du DELETE doit contenir?

REST est un style architectural défini par Fielding dans le chapitre 5 de sa thèse et il décrit un ensemble de contraintes pour les applications construites avec cette architecture. REST est conçu pour être indépendant du protocole mais le chapitre 6 de la même thèse décrit comment REST est appliqué sur HTTP.

Une fois que votre application REST est conçue en haut du protocole HTTP, vous devez être conscient de la sémantique HTTP. Et la sémantique du protocole HTTP/1.1 est actuellement décrite dans le RFC 7231 .

La charge utile de réponse d'une requête DELETE qui a réussi peut:

  • Soyez vide ou;
  • Inclure une représentation de l'état de l'action.

Et les codes d'état de réponse suivants conviennent à une demande DELETE qui a réussi:

  • 202 : La demande a été acceptée pour traitement, mais le traitement n'est pas terminé.
  • 204 : Le serveur a répondu à la demande et il n'y a pas de contenu supplémentaire à envoyer dans le corps de la charge utile de réponse.
  • 200 : la demande a réussi et la charge utile de la demande comprend une représentation de l'état de l'action.

Voir la citation suivante du RFC 7231 :

Si une méthode DELETE est appliquée avec succès, le serveur d'origine DEVRAIT envoyer un 202 (Accepté) code d'état si l'action réussira probablement mais n'a pas encore été exécutée, un 204 (Pas de contenu) code d'état si l'action a été exécutée et qu'aucune autre information n'est à fournir, ou 200 (OK) code d'état si l'action a été exécutée et que le message de réponse comprend une représentation décrivant l'état.

6
cassiomolin