Dezvoltarea API-urilor

Dezvoltarea aplicațiilor pe AWS

Ricardo Sueiras

Principal Technologist

Integrări API Gateway

 

• Mai multe opțiuni de integrare back-end
• HTTP: orice endpoint public rutabil
• API-uri de servicii AWS, precum DynamoDB sau SNS
• Funcții Lambda
• Resurse private prin link-uri VPC
• Răspunsuri mock fără un back-end real

Tipuri de integrare: proxy

 

• Tipul de integrare determină controlul exercitat de API Gateway
• Tipuri proxy: AWS_PROXY și HTTP_PROXY
• Cererea HTTP completă este trimisă direct la back-end
• API Gateway acționează ca un intermediar transparent
• Back-end-ul construiește răspunsul

Tipuri de integrare: non-proxy

• Tipuri non-proxy: AWS și HTTP
• Configurezi transformările cererii și răspunsului
• Bazate pe șabloane de mapare
• Șabloanele sunt scrise în Velocity Template Language (VTL)

 

Validarea cererilor

 

• Validează cererile înainte să ajungă la back-end
• Detectează câmpuri obligatorii lipsă
• Detectează format JSON invalid
• Detectează tipuri de parametri incorecte
• Erorile returnează de obicei 400 Bad Request

Validarea cererilor

 

• Validarea poate acoperi:
  • Headere
  • Parametri de tip query string
  • Corpul cererii
  • Schema JSON

Validarea cererilor

 

• Validarea aduce beneficii prin:
  • Reducerea cererilor invalide către back-end
  • Scăderea costului de execuție Lambda
  • Îmbunătățirea fiabilității API-ului

Transformări

• Restructurează cereri și răspunsuri fără a modifica codul back-end
  • Schimbă structura payload-ului
  • Redenumește câmpuri
  • Transformă headere
  • Convertește formate de date
  • Ascunde detalii de implementare
• Bazat pe șabloane de mapare VTL

 

Gestionarea erorilor

 

• Două categorii de erori
  • Erori de gateway: generate de API Gateway
  • Erori de integrare: defecțiuni ale back-end-ului
• Erori frecvente de gateway:
  • 400 Bad Request: validare a cererii eșuată
  • 429 Too Many Requests: limită de throttling depășită

Gestionarea erorilor

 

• Erori frecvente de integrare:
  • 502 Bad Gateway: răspuns malformat sau invalid
  • 503 Service Unavailable: back-end indisponibil sau supraîncărcat
  • 504 Gateway Timeout: timeout de 29 de secunde depășit
  • API-urile REST regionale și private pot extinde limita de 29 de secunde

Jurnalizare

• Jurnalele de execuție și metricile CloudWatch sunt instrumente esențiale de depanare
• API Gateway se integrează cu CloudWatch pentru:
  • Jurnale
  • Metrici
  • Urmărirea execuției

 

 

Jurnalizare

• Jurnalele CloudWatch te ajută să depanezi:
  • Integrări eșuate
  • Erori de transformare
  • Eșecuri de autorizare
  • Probleme de execuție Lambda

 

 

Stage-uri: gestionarea API-urilor în mai multe medii

 

• O singură definiție API deservește mai multe medii
• Stage-urile sunt modul în care API Gateway gestionează acele medii

Stage-uri: gestionarea API-urilor în mai multe medii

 

• O singură definiție API deservește mai multe medii
• Stage-urile sunt modul în care API Gateway gestionează acele medii
• Un stage este o referință denumită
• Indică un snapshot al configurației API-ului tău

Stage-uri: gestionarea API-urilor în mai multe medii

 

• O singură definiție API deservește mai multe medii
• Stage-urile sunt modul în care API Gateway gestionează acele medii
• Un stage este o referință denumită
• Indică un snapshot al configurației API-ului tău
• Nume uzuale de stage-uri:
  • Dev
  • Test
  • QA și Prod

Stage-uri: gestionarea API-urilor în mai multe medii

 

• O singură definiție API deservește mai multe medii
• Stage-urile sunt modul în care API Gateway gestionează acele medii
• Un stage este o referință denumită
• Indică un snapshot al configurației API-ului tău
• Nume uzuale de stage-uri: Dev, Test, QA, Prod
• URL-ul de invocare reflectă fiecare stage

Stage-uri: gestionarea API-urilor în mai multe medii

 

• O singură definiție API deservește mai multe medii
• Stage-urile sunt modul în care API Gateway gestionează acele medii
• Un stage este o referință denumită
• Indică un snapshot al configurației API-ului tău
• Nume uzuale de stage-uri: Dev, Test, QA, Prod
• URL-ul de invocare reflectă fiecare stage
• Mai multe stage-uri pot indica același deployment pentru rollback instant

Stage-uri: gestionarea API-urilor în mai multe medii

 

• Modificările intră în vigoare doar după ce sunt publicate într-un stage

Capabilități ale stage-urilor

• Fiecare stage este configurat independent
• Configurarea include variabile de stage
• Variabilele de stage sunt perechi cheie-valoare
• Direcționează un deployment către back-end-uri diferite
• Nu e nevoie de redesfășurare pentru schimbări de mediu

 

Capabilități ale stage-urilor

• Deployments canary
  • Doar pentru REST API-uri
  • Trimite un procent din trafic către un deployment nou
  • Promovează la lansare completă
  • Șterge canary-ul pentru rollback

 

Capabilități ale stage-urilor

• Throttling
  • Setat la nivelul stage-ului
  • Se aplică tuturor metodelor, cu suprașcrieri per metodă

 

Capabilități ale stage-urilor

• Throttling
  • Setat la nivelul stage-ului
  • Se aplică tuturor metodelor, cu suprașcrieri per metodă
• Caching
  • Doar pentru REST API-uri
  • Stochează răspunsurile back-end-ului la nivel de stage
  • Clienții pot ocoli cache-ul cu Cache-Control
  • TTL între 0 și 3600 secunde, implicit 300

 

Capabilități ale stage-urilor

• Jurnalizarea oferă două moduri
  • Jurnale de acces
  • Construite din variabilele $context, trimise către un grup de jurnale CloudWatch
  • Jurnale de execuție
  • Captează detalii complete ale cererii și răspunsului

 

Hai să exersăm!

Dezvoltarea aplicațiilor pe AWS