Ajout de ralentissements et de codes d'erreur - Construction d'un exemple d'API en C# Course

Introduction à l'API d'échantillonnage et à son objectif

Tim commence la leçon en rappelant l'intérêt de disposer d'un exemple d'API lors de l'apprentissage du développement web. Une telle API vous donne quelque chose de concret pour tester vos applications frontales.

À la fin du cours, Tim a pour objectif de construire une API robuste qui comprend :

• Exemple de données

• Documentation

• Contrôles de santé

• Simulation de ralentissements

• Erreurs simulées

• Options de déploiement via Docker et VPS

Dans cette leçon spécifique, Tim se concentre sur la simulation de ralentissements et la génération de codes d'erreur pour un comportement réaliste de l'API dans des conditions défavorables.

Ajouter des délais artificiels aux points de terminaison de l'API

Tim commence par ajouter un paramètre de délai facultatif à certains points de terminaison de l'API, en particulier ceux qui traitent des données de cours. Son objectif est de simuler des réponses API lentes afin d'améliorer les tests frontaux.

if (delay > 300000)
{
    delay = 300000;
}
await Task.Delay(delay.Value);

if (delay > 300000)
{
    delay = 300000;
}
await Task.Delay(delay.Value);

Tester le mécanisme de retardement

Tim effectue quelques tests à l'aide de Postman (ou d'un clone de Postman) pour vérifier la logique du délai. Par exemple:

• Un délai=5000 (5 secondes) provoque une pause dans l'API avant de renvoyer les résultats.

• Un délai = 500 entraîne une pause plus courte.

Il observe que le délai réel sera toujours légèrement supérieur à la valeur spécifiée en raison des frais généraux de traitement - une nuance importante dans le monde réel. Comme le note Tim à 5:09, vous ne chronométrez pas l'API à la milliseconde près, mais vous simulez plutôt un seuil.

Expansion de la fonctionnalité Delay à un plus grand nombre de points de terminaison

Tim ne s'arrête pas au point de terminaison "charger tous les cours". Dans un souci de cohérence, il implémente la même capacité de retard dans le point de terminaison "charger un cours par ID".

<À 6:15, il rencontre un problème : un conflit de dénomination dû à l'ajout automatique de "Async" au nom de la méthode lors de la conversion en asynchrone. Tim ajuste les noms des deux méthodes pour les aligner sur la convention de dénomination Async, dans un souci de clarté et de cohérence.

Les tests confirment la mise en œuvre :

• Les délais sont respectés.

• Les enregistrements inexistants renvoient 404 comme prévu après le délai.

• La suppression du délai ou le passage de valeurs vides se comporte de manière appropriée, Tim notant une bizarrerie de l'interface utilisateur de Postman plutôt qu'un problème avec l'API elle-même (8:00).

code switch
{
    400 => Results.BadRequest(),
    401 => Results.Unauthorized(),
    403 => Results.Forbid(),
    404 => Results.NotFound(),
    _   => Results.StatusCode(code)
};

code switch
{
    400 => Results.BadRequest(),
    401 => Results.Unauthorized(),
    403 => Results.Forbid(),
    404 => Results.NotFound(),
    _   => Results.StatusCode(code)
};

Tester le point final d'erreur

Tim teste maintenant le point de terminaison d'erreur en transmettant différents codes d'état :

• 400 renvoie "Bad Request" (mauvaise demande)

• 401 renvoie "Non autorisé"

• 404 renvoie "Not Found" (introuvable)

• 301 renvoie "Moved Permanently"

• 405 renvoie "Méthode non autorisée"

Cela montre la flexibilité du point de terminaison - pas seulement pour les codes d'erreur, mais pour n'importe quel code d'état HTTP. <À 13:04, Tim confirme que cette approche est idéale pour tester la façon dont les applications frontales gèrent les différentes réponses du serveur.

Bien qu'il ait envisagé de l'appeler /httpcode, il s'en tient à /error pour des raisons de simplicité, car il est principalement utilisé pour simuler des conditions d'erreur.

Résumé des améliorations fonctionnelles

Tim conclut la vidéo en résumant les améliorations apportées à l'API :

• les Slowdowns simulent la latence réelle des réponses API.

• la simulation d'erreurs permet de tester pratiquement toutes les réponses HTTP.

• Ces caractéristiques rendent l'exemple d'API plus robuste et inestimable pour des scénarios de test réalistes.

<À 14:16, Tim souligne l'importance de ces outils pour tester le comportement de votre application dans différents états de l'API, tels que des réponses retardées ou diverses erreurs de serveur.

Aujourd'hui : Dockeriser l'API

Bien qu'elle ne soit pas abordée en détail dans cette vidéo, Tim fait allusion à l'étape suivante : Dockeriser l'API. Cela permet aux développeurs d'exécuter l'exemple d'API localement dans un conteneur Docker autonome, ce qui facilite le déploiement et le partage dans différents environnements.

Conclusion

Tim conclut la vidéo en réitérant son engagement à créer un échantillon complet d'API qui inclut des fonctionnalités réalistes que les développeurs ont réellement besoin de tester. Il s'agit notamment de

• Délais

• Erreurs

• Contrôles de santé

• Projets futurs pour l'authentification et les points de terminaison avancés

L'objectif est simple mais puissant : doter les développeurs d'un outil qui imite les bizarreries des API réelles, afin que leurs applications soient robustes, fiables et conviviales.

Conclusion

À la fin de cette leçon, les spectateurs auront une meilleure compréhension de comment et pourquoi introduire des délais artificiels et des réponses d'erreur dans leurs API. L'approche de Tim Corey est méthodique, pratique et directement liée aux besoins de tests d'applications réelles. Si vous cherchez à améliorer vos tests d'API, cette leçon est une excellente ressource à suivre - et vous savez maintenant exactement où chercher.

Regardez la leçon complète de Tim Corey pour obtenir des conseils pratiques.