Gestion des erreurs et tests des API REST

Name: Gestion des erreurs et tests des API REST
Author: Josh Guardino

Apprenez à gérer les erreurs d’API REST et à créer et exécuter des tests automatisés

Preview the first lesson free — get full access to all 3 lessons.

Cours : à la demande

Bonjour, je m'appelle Josh Gardino, et dans ces leçons, je vais vous montrer comment gérer les erreurs et tester les API REST. Rappelez-vous que les codes d'état de réponse HTTP sont divisés en plusieurs groupes. Les codes d'état compris entre 400 et 500 sont considérés comme des erreurs. Cependant, la différence critique est que les codes d'état commençant par quatre sont des erreurs client et les codes d'état commençant par cinq sont des erreurs de serveur. Les erreurs client seraient des erreurs liées à la demande elle-même. La requête peut contenir du JSON mal formaté, l'accès au chemin demandé était interdit, la ressource demandée est introuvable, et plus encore. Lorsque des erreurs client se produisent, il est important que le serveur réponde avec le bon code d'état de la série 400. Cependant, en conservant tous les détails à propos de l'erreur client n'est normalement pas nécessaire côté serveur. Le client doit être en mesure de résoudre le problème et envoyer une nouvelle demande. Plus préoccupant côté serveur sont les codes d'erreur du serveur, et ce sont ceux qui commencent par cinq. Bien qu'il existe de nombreux codes de réponse d'erreur de serveur, de loin, le plus important et le plus pertinent est 500. 500 indique une erreur de serveur interne pour une condition inattendue côté serveur, ce qui signifie qu'une erreur s'est produite. Le code d'état 500 est destiné être une réponse fourre-tout générique. Cependant, c'est généralement le seul type du code d'erreur côté serveur que le code côté serveur de l'API REST doit gérer. D'autres codes d'erreur côté serveur peuvent être rencontrés par un client, comme 503 indiquant que le serveur n'est pas prêt. Mais ces types de réponses sont généralement envoyés par une passerelle API et non par l'application elle-même. Nous allons jeter un coup d'oeil au Department of Motor Vehicles API de Postman. Voici le point de terminaison v1/drivers GET et lorsque je clique sur Envoyer, un code d'état 200 est renvoyé et une liste de tous les pilotes de la base de données. Voyons maintenant à quoi cela ressemble dans le code source. Voici le gestionnaire de la méthode GET. Il effectue une requête de sélection sur la base de données et renvoie toutes les données. Cela fonctionne bien si aucune erreur n'est rencontrée. Cependant, forçons une erreur à se produire. À la ligne 12, je vais entrer un code invalide. Redémarrons le serveur et revenons à Postman. Je vais cliquer sur envoyer et comme vous pouvez le voir, Je n'ai pas reçu de code d'état ni aucun type de réponse. Postman affiche une erreur ECONNRESET. Cela signifie que le serveur n'a pas répondu avec tout ce que Postman pourrait traiter. Revenons à l'endroit où le serveur est en cours d'exécution. Mon serveur local a détecté avec précision l'erreur xyz et affiché tous les détails dans la fenêtre de la console. Ces détails sont appelés une trace de pile et ils sont très importants à des fins de débogage. La première ligne de la sortie d'erreur me dit qu'il s'agissait d'une erreur de référence parce que le serveur n'a pas compris ce qu'est xyz, donc l'erreur est capturée correctement mais le client n'a aucune idée de ce qui s'est passé. Le serveur pourrait être en panne, il pourrait y avoir un problème de réseau côté client, il peut y avoir une erreur côté serveur mais le client n'a aucun moyen de savoir ce qui s'est passé et c'est parce que ce code n'exécute aucun type de la gestion des erreurs. Lorsque l'erreur se produit, le serveur détecte que quelque chose s'est mal passé mais aucune réponse n'est envoyée car pour la méthode GET, le seul type de réponse envoyé est un 200. Maintenant, ajoutons un peu de gestion des erreurs à l'application Node.js Express avec des instructions try et catch. Maintenant, l'erreur est gérée et toutes les erreurs seront rattrapées à la ligne 16. Sur la ligne 17, j'envoie un statut de 500 au client. Revenons à Postman et essayons ceci. Maintenant, quand j'envoie la demande, Je reçois une réponse et elle a un code d'état 500 indiquant une erreur de serveur interne. Le client ne sait pas exactement ce qui s'est passé côté serveur, mais il a beaucoup plus d'informations qu'avec la demande précédente. Il est certainement possible d'envoyer les détails complets de l'erreur au client, avec le code d'état d'erreur interne du serveur 500 mais c'est certainement problématique. Plus important encore, cela expose les détails internes à propos de l'API et cela présente un problème de sécurité potentiellement grave mais aussi, ces informations ne sont pas utiles pour le client, il n'y a donc aucune raison de l'envoyer mais cela ne signifie pas que le serveur doit renvoyer un message de réponse générique du serveur. Revenons au code et ajoutez un message d'erreur convivial. Maintenant, lorsque nous envoyons cette demande, nous recevons toujours un 500 mais avec un message d'erreur personnalisé. Une autre raison d'utiliser un message de code d'état 500 personnalisé est de fournir au client un suivi ou ID de corrélation que le personnel côté client de l'API pourrait partager avec le personnel côté serveur afin d'effectuer un dépannage détaillé. Merci d'avoir regardé. Restez à l'écoute pour la prochaine leçon où je vais vous montrer comment utiliser les tests automatisés pour les requêtes GET dans l'API REST.

Débutant Fournisseur : Josh Guardino 3 leçons · 17m en Arabe, Allemand, Anglais, Espagnol, Français, Portugais, Chinese

Description du cours

Les API sont, de par leur nature, des applications logicielles distribuées qui consistent en des clients distants et des serveurs se connectant sur un réseau. Bien que la communication à distance ait changé le monde tel que nous le connaissons, elle apporte également une énorme liste de pièges et de problèmes potentiels. Les serveurs et les réseaux tombent en panne. Les ordinateurs peuvent agir de manière inattendue. Les clients changent et ne peuvent pas traiter les demandes et les réponses. Tout cela s’ajoute à une vérité constante: le seul facteur connu est l’inconnu.

Pour gérer les imprévus, il est important que les clients et serveurs RESTful traitent ces conditions avec élégance. Dans ces leçons, vous apprendrez comment les erreurs se produisent des deux côtés et comment la combinaison des détails d’erreur, des codes d’état et des messages peut être traitée de manière optimale.

La meilleure défense contre l’instabilité et l’incohérence d’un logiciel est de le tester régulièrement et régulièrement. Nous vous montrerons comment utiliser TestProject, un outil Web gratuit, pour scripter et automatiser les tests de l’API REST afin de découvrir et d’identifier les conditions d’erreur et de fournir des informations utiles pour le débogage et le réglage des performances.

Ce que vous allez apprendre

Identifier les types d'erreurs d'API REST les plus courants et leurs codes d'état correspondants
Reconnaître comment les erreurs se produisent à la fois côté client et côté serveur d'une API
Traiter les détails des erreurs, les codes d'état et les messages de manière optimale pour gérer l'inattendu avec grâce
Configurer et exécuter TestProject pour scripter et automatiser des tests d'API REST pour les requêtes GET
Configurer et exécuter TestProject pour les requêtes POST, PUT, PATCH et d'autres requêtes d'écriture
Utiliser des tests d'API REST automatisés pour découvrir des conditions d'erreur et fournir des informations pour le débogage et l'optimisation des performances

Points clés à retenir

Les API sont des applications distribuées de clients et de serveurs distants se connectant via un réseau, ce qui introduit de nombreux pièges potentiels, tels que des pannes de serveurs ou de réseaux, ou des clients échouant à traiter les requêtes et les réponses.
Les clients et les serveurs RESTful doivent gérer gracieusement les conditions inattendues en combinant les détails des erreurs, les codes d'état et les messages, et en les traitant de manière optimale.
Des tests cohérents et réguliers constituent la meilleure défense contre l'instabilité et l'incohérence des logiciels.
TestProject est un outil gratuit basé sur le Web utilisé pour scripter et automatiser les tests d'API REST afin d'identifier les conditions d'erreur et de soutenir le débogage et l'optimisation des performances.
Le cours couvre le traitement des requêtes GET ainsi que des requêtes d'écriture telles que POST, PUT et PATCH.

Foire aux questions

Que couvre ce cours ?

Il couvre la façon dont les erreurs se produisent à la fois côté client et côté serveur des API REST, la manière dont les détails d'erreurs, les codes d'état et les messages peuvent être traités de manière optimale, et comment utiliser TestProject pour scripter et automatiser les tests d'API REST afin de découvrir des conditions d'erreur et de soutenir le débogage et l'optimisation des performances.

Quel outil de test est utilisé dans ce cours ?

Le cours utilise TestProject, un outil web gratuit, pour scripter et automatiser les tests d'API REST.

Quels types de requêtes d'API le cours apprend-il à tester ?

Il enseigne la configuration et l'exécution de TestProject pour les requêtes GET, ainsi que pour les requêtes POST, PUT, PATCH et autres requêtes d'écriture.

Quelles compétences ce cours permet-il de développer ?

Il aborde des compétences telles que la conception d'API, la gestion d'API, les tests d'API, le développement d'API REST, les clients REST et les API RESTful.

Quelles leçons sont incluses dans ce cours ?

Le cours comprend trois leçons : La gestion des erreurs et les tests des API REST ; Les méthodes HTTP GET ; et Les requêtes POST, PUT et PATCH.