Développement d'API

Développer des applications sur AWS

Ricardo Sueiras

Principal Technologist

Intégrations d'API Gateway

 

• Plusieurs options d'intégration au serveur dorsal
• HTTP : tout point de terminaison public
• API de services AWS comme DynamoDB ou SNS
• Fonctions Lambda
• Ressources privées via des liens VPC
• Réponses simulées sans serveur dorsal réel

Types d'intégration : mandataire

 

• Le type d'intégration fixe le degré de contrôle d'API Gateway
• Types mandataires : AWS_PROXY et HTTP_PROXY
• La requête HTTP complète est transmise au serveur dorsal
• API Gateway agit en relais transparent
• Le serveur dorsal compose la réponse

Types d'intégration : non mandataire

• Types non mandataires : AWS et HTTP
• Vous définissez les transformations requête/réponse
• Basées sur des gabarits de mappage
• Gabarits écrits en Velocity Template Language (VTL)

 

Validation des requêtes

 

• Valider les requêtes avant le serveur dorsal
• Détecte les champs obligatoires manquants
• Détecte le format JSON invalide
• Détecte les types de paramètres erronés
• Les échecs renvoient généralement 400 Bad Request

Validation des requêtes

 

• La validation peut couvrir :
  • En-têtes
  • Paramètres de chaîne de requête
  • Corps de la requête
  • Schéma JSON

Validation des requêtes

 

• La validation rapporte par :
  • Moins de requêtes invalides au serveur dorsal
  • Coût d'exécution Lambda réduit
  • Fiabilité de l'API améliorée

Transformations

• Remodeler requêtes et réponses sans toucher au code dorsal
  • Modifier la structure de la charge utile
  • Renommer des champs
  • Transformer des en-têtes
  • Convertir des formats de données
  • Masquer des détails d'implémentation
• Propulsé par des gabarits VTL de mappage

 

Gestion des erreurs

 

• Deux catégories d'erreurs
  • Erreurs de passerelle : émises par API Gateway
  • Erreurs d'intégration : pannes du serveur dorsal
• Erreurs de passerelle courantes :
  • 400 Bad Request : validation de requête échouée
  • 429 Too Many Requests : limite d'étranglement dépassée

Gestion des erreurs

 

• Erreurs d'intégration courantes :
  • 502 Bad Gateway : réponse mal formée ou invalide
  • 503 Service Unavailable : serveur dorsal indisponible ou surchargé
  • 504 Gateway Timeout : délai de 29 s dépassé
  • Les API REST régionales et privées peuvent dépasser 29 s

Journalisation

• Les journaux d'exécution et les mesures CloudWatch sont essentiels au dépannage
• API Gateway s'intègre à CloudWatch pour :
  • Journaux
  • Mesures
  • Traçage d'exécution

 

 

Journalisation

• Les journaux CloudWatch aident à dépanner :
  • Intégrations échouées
  • Erreurs de transformation
  • Échecs d'autorisation
  • Problèmes d'exécution Lambda

 

 

Étapes : gérer des API entre environnements

 

• Une définition d'API dessert plusieurs environnements
• Les étapes sont le mécanisme de gestion d'API Gateway

Étapes : gérer des API entre environnements

 

• Une définition d'API dessert plusieurs environnements
• Les étapes sont le mécanisme de gestion d'API Gateway
• Une étape est une référence nommée
• Elle pointe vers un instantané de déploiement de la config de votre API

Étapes : gérer des API entre environnements

 

• Une définition d'API dessert plusieurs environnements
• Les étapes sont le mécanisme de gestion d'API Gateway
• Une étape est une référence nommée
• Elle pointe vers un instantané de déploiement de la config de votre API
• Noms d'étapes fréquents :
  • Dev
  • Test
  • QA et Prod

Étapes : gérer des API entre environnements

 

• Une définition d'API dessert plusieurs environnements
• Les étapes sont le mécanisme de gestion d'API Gateway
• Une étape est une référence nommée
• Elle pointe vers un instantané de déploiement de la config de votre API
• Noms d'étapes fréquents : Dev, Test, QA, Prod
• L'URL d'invocation reflète chaque étape

Étapes : gérer des API entre environnements

 

• Une définition d'API dessert plusieurs environnements
• Les étapes sont le mécanisme de gestion d'API Gateway
• Une étape est une référence nommée
• Elle pointe vers un instantané de déploiement de la config de votre API
• Noms d'étapes fréquents : Dev, Test, QA, Prod
• L'URL d'invocation reflète chaque étape
• Plusieurs étapes peuvent viser un même déploiement pour un retour arrière instantané

Étapes : gérer des API entre environnements

 

• Les changements sont actifs seulement une fois déployés dans une étape

Capacités des étapes

• Chaque étape est configurée indépendamment
• La configuration inclut des variables d'étape
• Les variables d'étape sont des paires clé-valeur
• Acheminer un déploiement vers différents serveurs dorsaux
• Aucun redéploiement requis pour changer d'environnement

 

Capacités des étapes

• Déploiements canari
  • REST APIs seulement
  • Diriger un pourcentage du trafic vers un nouveau déploiement
  • Promouvoir en diffusion complète
  • Supprimer le canari pour revenir en arrière

 

Capacités des étapes

• Étranglement
  • Défini au niveau de l'étape
  • S'applique à toutes les méthodes, sauf dérogations par méthode

 

Capacités des étapes

• Étranglement
  • Défini au niveau de l'étape
  • S'applique à toutes les méthodes, sauf dérogations par méthode
• Mise en cache
  • REST APIs seulement
  • Stocke les réponses du serveur dorsal à l'étape
  • Les clients contournent avec Cache-Control
  • TTL de 0 à 3600 s, 300 par défaut

 

Capacités des étapes

• La journalisation offre deux modes
  • Journaux d'accès
  • Construits à partir des variables $context, envoyés à un groupe de journaux CloudWatch
  • Journaux d'exécution
  • Capturent le détail complet des requêtes et réponses

 

Passons à la pratique !

Développer des applications sur AWS