J'écris une API RESTful dans Nest, que j'ai récemment commencé à utiliser et que j'aime jusqu'à présent. Cependant, j'ai du mal à trouver un modèle propre pour gérer 204 réponses sans contenu pour mes routes GET. Des recommandations?
Je suis un peu surpris qu'il n'y ait pas quelque chose de intégré dans le framework pour renvoyer 204 si l'objet retourné par une méthode de contrôleur GET est vide - s'il y en a, je ne l'ai pas encore trouvé. S'il n'y en a vraiment pas, je me demande également si cela vaut une demande de fonctionnalité sur GitHub.
J'ai essayé ce qui suit:
@Response() comme paramètre de méthode Controller, puis en utilisant res.sendStatus(204) si la réponse est vide. Cependant, cela m'oblige également à envoyer manuellement 200 réponses, alors que je voudrais toujours me fier au framework pour gérer le cycle demande-réponse et garder mes méthodes de contrôleur aussi propres que possible.NoContentException personnalisée pour mon filtre d'exception à gérer. Bien qu'il soit étrange de lancer une exception pour un code de réponse réussi, je pense que c'est ainsi que je procéderai entre-temps, car mon filtre d'exception est la dernière chose qui s'exécutera dans le code que j'ai écrit.3 Réponses :
Depuis la v6.1.0, il est possible de définir le code de réponse dans un intercepteur, voir ce PR .
Malheureusement, cela ne semble pas encore possible. Dans les documents, il est dit:
Souvent, votre code d'état n'est pas statique mais dépend de divers facteurs. Dans ce cas, vous pouvez utiliser un objet de réponse spécifique à la bibliothèque (injecter à l'aide de
@Res()) (ou, en cas d'erreur, lever une exception).
Vous ne pouvez pas non plus simplement définir le code de réponse dans un Interceptor sans l'envoyer (au lieu de sendStatus ) car, comme Kamil l'a dit dans ce fil :
La logique du contrôleur de réponse globale est la dernière étape effectuée juste avant l'envoi d'un résultat final via le réseau (c'est là que les codes d'état par défaut entrent en jeu).
Donc, si vous ne voulez (naturellement) pas utiliser @Res dans chaque contrôleur, un ExceptionFilter semble être la meilleure option, même si cela ne semble pas tout à fait correct.
Étant donné que d'autres personnes semblent avoir exactement le même problème , une demande de fonctionnalité peut être une bonne idée. :-)
J'ai trouvé ces réponses (également de @ kim-kern) utiles également lorsque j'ai rencontré cette situation: stackoverflow.com/questions/55406194/... stackoverflow.com/questions/51695868/...
À propos de l'idée de générer une réponse 204 en vérifiant si le contenu de la réponse est vide
cela pourrait être possible et réalisable dans la programmation Express.js directement ou dans la construction d'un intercepteur en tant que plugin middleware dans l'utilisation du framework nestjs, comme mentionné dans la réponse @ kim-kern .
Cependant, au niveau de la conception de l'API, ce n'est pas une fonctionnalité requise car une API doit idéalement être conçue comme une réponse de réussite, ce qui signifie qu'un seul code de réussite serait disponible pour un point de terminaison. De ce point de vue, l'annotation du code d'état pourrait être acceptable.
En regardant cet exemple :
@Post()
@HttpCode(204)
create() {
return 'This action adds a new cat';
}
C'est tout ce que vous devez faire. Il revient à 204 pour vous.
Il existe une énumération pour les codes d'état HTTP: HttpStatus. Vous pouvez donc faire: @HttpCode (HttpStatus.NO_CONTENT)
Nice, je ne savais pas à ce sujet.
voir la mise à jour dans ma réponse, c'est désormais possible avec les intercepteurs. :-)