Développement d'API

Développer des applications sur AWS

Ricardo Sueiras

Principal Technologist

Intégrations API Gateway

 

• Plusieurs options d'intégration back-end
• HTTP : tout endpoint public routable
• APIs de services AWS comme DynamoDB ou SNS
• Fonctions Lambda
• Ressources privées via des liens VPC
• Réponses simulées sans vrai back-end

Types d'intégration : proxy

 

• Le type d'intégration définit le contrôle d'API Gateway
• Types proxy : AWS_PROXY et HTTP_PROXY
• Toute la requête HTTP est envoyée directement au back-end
• API Gateway agit en simple passe-plat
• Le back-end construit la réponse

Types d'intégration : non‑proxy

• Types non‑proxy : AWS et HTTP
• Vous configurez les transformations requête/réponse
• Pilotées par des modèles de mappage
• Modèles écrits en Velocity Template Language (VTL)

 

Validation des requêtes

 

• Valider les requêtes avant le back-end
• Détecte les champs obligatoires manquants
• Détecte le JSON invalide
• Détecte les types de paramètres incorrects
• 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 requête
  • Schéma JSON

Validation des requêtes

 

• La validation apporte :
  • Moins de requêtes back-end invalides
  • Moindre coût d'exécution Lambda
  • Fiabilité accrue de l'API

Transformations

• Remodeler requêtes et réponses sans toucher au code back-end
  • Modifier la structure du payload
  • Renommer des champs
  • Transformer des en‑têtes
  • Convertir des formats de données
  • Masquer des détails d'implémentation
• Bâti sur des modèles de mappage VTL

 

Gestion des erreurs

 

• Deux catégories d'erreurs
  • Erreurs de passerelle : levées par API Gateway
  • Erreurs d'intégration : échecs back-end
• Erreurs de passerelle courantes :
  • 400 Bad Request : validation de requête échouée
  • 429 Too Many Requests : limite de limitation dépassée

Gestion des erreurs

 

• Erreurs d'intégration courantes :
  • 502 Bad Gateway : réponse mal formée ou erronée
  • 503 Service Unavailable : back-end indisponible ou saturé
  • 504 Gateway Timeout : dépassement du délai de 29 secondes
  • Les API REST régionales et privées peuvent dépasser 29 secondes

Journalisation

• Les journaux d'exécution et métriques CloudWatch sont clés pour le diagnostic
• API Gateway s'intègre à CloudWatch pour :
  • Journaux
  • Métriques
  • Traçage d'exécution

 

 

Journalisation

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

 

 

Étapes : gérer les API selon les environnements

 

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

Étapes : gérer les API selon les environnements

 

• Une définition d'API sert 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 les API selon les environnements

 

• Une définition d'API sert 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 courants :
  • Dev
  • Test
  • QA et Prod

Étapes : gérer les API selon les environnements

 

• Une définition d'API sert 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 courants : Dev, Test, QA, Prod
• L'URL d'invocation reflète chaque étape

Étapes : gérer les API selon les environnements

 

• Une définition d'API sert 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 courants : Dev, Test, QA, Prod
• L'URL d'invocation reflète chaque étape
• Plusieurs étapes peuvent pointer vers un même déploiement pour un rollback instantané

Étapes : gérer les API selon les environnements

 

• Les changements ne sont effectifs qu'après déploiement sur 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
• Router un même déploiement vers différents back‑ends
• Pas de redéploiement pour changer d'environnement

 

Capacités des étapes

• Déploiements canary
  • REST APIs uniquement
  • Envoyer un pourcentage du trafic vers un nouveau déploiement
  • Promouvoir en mise en production complète
  • Supprimer le canary pour revenir en arrière

 

Capacités des étapes

• Limitation (throttling)
  • Définie au niveau de l'étape
  • S'applique à toutes les méthodes, avec dérogations par méthode

 

Capacités des étapes

• Limitation (throttling)
  • Définie au niveau de l'étape
  • S'applique à toutes les méthodes, avec dérogations par méthode
• Mise en cache
  • REST APIs uniquement
  • Stocke les réponses back-end au niveau de l'étape
  • Les clients peuvent l'ignorer avec Cache-Control
  • TTL de 0 à 3 600 s, valeur par défaut 300

 

Capacités des étapes

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

 

Passons à la pratique !

Développer des applications sur AWS