API-Entwicklung

Anwendungen auf AWS entwickeln

Ricardo Sueiras

Principal Technologist

API-Gateway-Integrationen

 

• Mehrere Back-End-Integrationsoptionen
• HTTP: jeder öffentlich erreichbare Endpunkt
• AWS-Service-APIs wie DynamoDB oder SNS
• Lambda-Funktionen
• Private Ressourcen über VPC-Links
• Mock-Antworten ohne echtes Back-End

Integrationstypen: Proxy

 

• Integrationstyp bestimmt, wie viel Kontrolle API Gateway hat
• Proxy-Typen: AWS_PROXY und HTTP_PROXY
• Gesamte HTTP-Anfrage geht direkt ans Back-End
• API Gateway schleust transparent durch
• Back-End erstellt die Antwort

Integrationstypen: Nicht-Proxy

• Nicht-Proxy-Typen: AWS und HTTP
• Du konfigurierst Request- und Response-Transformationen
• Gesteuert durch Mapping-Vorlagen
• Vorlagen in Velocity Template Language (VTL)

 

Request-Validierung

 

• Anfragen validieren, bevor sie das Back-End erreichen
• Erkennt fehlende Pflichtfelder
• Erkennt ungültiges JSON-Format
• Erkennt falsche Parametertypen
• Fehler liefern meist 400 Bad Request

Request-Validierung

 

• Validierung kann abdecken:
  • Header
  • Query-String-Parameter
  • Request-Body
  • JSON-Schema

Request-Validierung

 

• Validierung zahlt sich aus durch:
  • Weniger ungültige Back-End-Anfragen
  • Niedrigere Lambda-Ausführungskosten
  • Höhere API-Zuverlässigkeit

Transformationen

• Requests und Responses umformen, ohne Back-End-Code anzupassen
  • Payload-Struktur ändern
  • Felder umbenennen
  • Header transformieren
  • Datenformate konvertieren
  • Implementierungsdetails verbergen
• Betrieben durch VTL-Mapping-Vorlagen

 

Fehlerbehandlung

 

• Zwei Fehlerkategorien
  • Gateway-Fehler: von API Gateway ausgelöst
  • Integrationsfehler: Back-End-Ausfälle
• Häufige Gateway-Fehler:
  • 400 Bad Request: fehlgeschlagene Request-Validierung
  • 429 Too Many Requests: Drosselgrenze überschritten

Fehlerbehandlung

 

• Häufige Integrationsfehler:
  • 502 Bad Gateway: fehlerhafte oder ungültige Antwort
  • 503 Service Unavailable: Back-End nicht verfügbar oder überlastet
  • 504 Gateway Timeout: 29-Sekunden-Timeout überschritten
  • Regionale und Private REST-APIs können über 29 Sekunden hinausgehen

Logging

• Ausführungslogs und CloudWatch-Metriken sind zentrale Tools zur Fehlersuche
• API Gateway integriert CloudWatch für:
  • Logs
  • Metriken
  • Ausführungstracing

 

 

Logging

• CloudWatch-Logs helfen bei der Fehlersuche:
  • Fehlgeschlagene Integrationen
  • Transformationsfehler
  • Autorisierungsfehler
  • Lambda-Ausführungsprobleme

 

 

Stages: APIs über Umgebungen steuern

 

• Eine API-Definition bedient mehrere Umgebungen
• Stages sind die Verwaltungsebene von API Gateway für diese Umgebungen

Stages: APIs über Umgebungen steuern

 

• Eine API-Definition bedient mehrere Umgebungen
• Stages sind die Verwaltungsebene von API Gateway für diese Umgebungen
• Ein Stage ist eine benannte Referenz
• Verweist auf einen Deployment-Snapshot deiner API-Konfiguration

Stages: APIs über Umgebungen steuern

 

• Eine API-Definition bedient mehrere Umgebungen
• Stages sind die Verwaltungsebene von API Gateway für diese Umgebungen
• Ein Stage ist eine benannte Referenz
• Verweist auf einen Deployment-Snapshot deiner API-Konfiguration
• Gängige Stage-Namen:
  • Dev
  • Test
  • QA und Prod

Stages: APIs über Umgebungen steuern

 

• Eine API-Definition bedient mehrere Umgebungen
• Stages sind die Verwaltungsebene von API Gateway für diese Umgebungen
• Ein Stage ist eine benannte Referenz
• Verweist auf einen Deployment-Snapshot deiner API-Konfiguration
• Gängige Stage-Namen: Dev, Test, QA, Prod
• Die Invoke-URL spiegelt jedes Stage wider

Stages: APIs über Umgebungen steuern

 

• Eine API-Definition bedient mehrere Umgebungen
• Stages sind die Verwaltungsebene von API Gateway für diese Umgebungen
• Ein Stage ist eine benannte Referenz
• Verweist auf einen Deployment-Snapshot deiner API-Konfiguration
• Gängige Stage-Namen: Dev, Test, QA, Prod
• Die Invoke-URL spiegelt jedes Stage wider
• Mehrere Stages können auf ein Deployment zeigen für sofortiges Rollback

Stages: APIs über Umgebungen steuern

 

• Änderungen gehen erst live, wenn sie in ein Stage deployed sind

Stage-Funktionen

• Jedes Stage wird separat konfiguriert
• Konfiguration umfasst Stage-Variablen
• Stage-Variablen sind Schlüssel-Wert-Paare
• Ein Deployment zu verschiedenen Back-Ends routen
• Keine erneute Bereitstellung bei Umweltwechsel nötig

 

Stage-Funktionen

• Canary-Deployments
  • Nur REST-APIs
  • Prozentsatz des Traffics an ein neues Deployment senden
  • Zur Vollversion hochstufen
  • Canary löschen, um zurückzurollen

 

Stage-Funktionen

• Drosselung
  • Auf Stage-Ebene festlegen
  • Gilt für alle Methoden, mit methodenspezifischen Ausnahmen

 

Stage-Funktionen

• Drosselung
  • Auf Stage-Ebene festlegen
  • Gilt für alle Methoden, mit methodenspezifischen Ausnahmen
• Caching
  • Nur REST-APIs
  • Speichert Back-End-Antworten je Stage
  • Clients umgehen mit Cache-Control
  • TTL 0 bis 3600 Sekunden, Standard 300

 

Stage-Funktionen

• Logging bietet zwei Modi
  • Access-Logs
  • Aus $context-Variablen gebaut, an eine CloudWatch-Log-Gruppe gesendet
  • Execution-Logs
  • Erfassen vollständige Request- und Response-Details

 

Lass uns üben!

Anwendungen auf AWS entwickeln