50 lines
1.5 KiB
Markdown
50 lines
1.5 KiB
Markdown
---
|
|
title: API Gateway
|
|
created: 2026-06-06
|
|
updated: 2026-06-06
|
|
type: concept
|
|
tags: [tech, architecture, networking]
|
|
confidence: high
|
|
contested: false
|
|
sources: [synthesized]
|
|
---
|
|
# 🚪 API Gateway
|
|
|
|
## Définition Courte
|
|
Serveur unique servant de **point d'entrée** pour toutes les APIs d'un système, gérant l'auth, le routage, le rate limiting et l'observabilité de manière centralisée.
|
|
|
|
## Explication Détaillée
|
|
Sans API Gateway, chaque microservice expose ses propres endpoints et le client doit connaître toutes les URLs. Avec une gateway, le client parle à un seul point qui dispatche.
|
|
|
|
Responsabilités typiques :
|
|
- **Routage** : `/users/*` $\rightarrow$ service users, `/orders/*` $\rightarrow$ service orders.
|
|
- **Auth** : vérification du token avant de router.
|
|
- **Rate limiting** : protection contre les abus.
|
|
- **Transformation** : convertir le format de requête (REST $\leftrightarrow$ gRPC).
|
|
- **Observabilité** : tracer toutes les requêtes.
|
|
|
|
## Cas d'Usage
|
|
- Architecture microservices.
|
|
- API publique avec plusieurs services backend.
|
|
- Legacy modernization (façade devant un vieux SOAP).
|
|
|
|
## Outils Liés
|
|
- **Kong** (open-core, plugins).
|
|
- **Traefik** (Docker-native).
|
|
- **Envoy** (utilisé par Istio).
|
|
- **AWS API Gateway**, **GCP API Gateway** (cloud).
|
|
|
|
## Pages Liées
|
|
- [[load-balancing]]
|
|
- [[architecture-microservices]]
|
|
- [[zero-trust]]
|
|
- [[traefik]]
|
|
|
|
## Questions Ouvertes
|
|
- L'API Gateway est-il remplacé par les Service Mesh ?
|
|
- Comment éviter que la gateway devienne un SPOF ?
|
|
|
|
## Liens
|
|
- [[rate-limiting]]
|
|
- [[cache]]
|