Styles d'API modernes (Course #api-styles)
For développeurs, architectes.
À la fin, vous saurez
À l'issue de cette formation, vous serez capable de trancher, cas d'usage par cas d'usage, entre REST, GraphQL, gRPC, WebSocket/SSE et AMQP et d'implémenter le temps réel sur Anypoint, décision documentée à l'appui.
Cas fil rouge
Aurora Mobility fait tourner sa plateforme de flotte sur 120 API REST ; les partenaires exigent gRPC pour la télémétrie, l'équipe mobile souffre du sur-fetching et le mur d'ops veut des mises à jour à la seconde. L'architecture doit arbitrer protocole par cas d'usage sous NFR : lecture p95 < 150 ms, diffusion à 50 000 clients WebSocket simultanés, zéro rupture des contrats REST existants.
Programme chaque ligne est quelque chose que vous faites
5 modules · 13 sujets · dans l'ordre du cours
-
Module 1
Apparier protocole et cas d'usage
Objectif. Comparer cinq styles d'API sur latence, couplage et outillage, puis produire une matrice de décision pour votre patrimoine.
- Noter REST/JSON, GraphQL, gRPC/Protobuf, WebSocket/SSE et AMQP 1.0 sur latence, taille de payload et couplage
- Appliquer le framework de décision à 3 cas d'usage réels en consignant les arbitrages (streaming vs polling, typage vs flexibilité)
-
Module 2
GraphQL sans les pièges
Objectif. Exposer des resolvers pilotés par schéma sur Anypoint et chiffrer le gain de payload face à des projections REST figées.
- Modéliser un schéma et câbler des resolvers avec le connecteur GraphQL, en composant les API système derrière un endpoint unique
- Réduire les payloads mobiles grâce aux requêtes définies par le client (cible : −40 % d'octets transférés vs REST)
- Plafonner profondeur et complexité de requête pour bloquer les tempêtes N+1 et l'introspection abusive
-
Module 3
Temps réel qui tient la charge
Objectif. Exploiter un backbone WebSocket pub/sub dimensionné pour des dizaines de milliers de clients simultanés.
- Implémenter le pub/sub avec le connecteur WebSocket : handshake, heartbeats, reconnexion avec backoff + jitter
- Répartir les sessions entre workers CloudHub/RTF (cible : 50 000 sockets simultanés par cluster)
- Revenir au SSE quand un flux unidirectionnel suffit, en comparant les garanties de livraison par canal
- Recevoir les webhooks défensivement : vérifier la signature HMAC, répondre vite en 202 Accepted, traiter ensuite hors bande
- Dédoublonner les récepteurs par event-id via Object Store pour qu'aucun retry fournisseur ne déclenche deux fois la même mise à jour
-
Module 4
Gouverner le trafic non-REST
Objectif. Étendre l'application des policies API Manager aux endpoints GraphQL et WebSocket, résultats vérifiés à l'appui.
- Appliquer OAuth 2.0 et rate limiting aux endpoints GraphQL et WebSocket via API Manager / Flex Gateway
- Étrangler les raz-de-marée d'abonnements par token bucket (p. ex. 10 msg/s par client) et surveiller les hits de policy
-
Module 5
Lab : mur d'ops temps réel
Objectif. Livrer la chaîne du lab : API système REST alimentant un dashboard diffusé par WebSocket, tracée de bout en bout.
- Construire la chaîne dashboard temps réel — API système REST → API process → API experience WebSocket — tracée de bout en bout
Références & documentation officielle chaque affirmation ci-dessus a une source
Module 1
- Présentation d'APIkitDoc MuleSoft
Module 2
- APIkit pour GraphQLDoc MuleSoft
- Politique GraphQL Operation LimitsDoc MuleSoft
Module 3
- RFC 6455 — Le protocole WebSocketSpécification
- Connecteur WebSocketsDoc MuleSoft
- Reconnexion WebSocketsDoc MuleSoft
Module 4
- Politique GraphQL Static Query ComplexityDoc MuleSoft
- Politique de limitation de débitDoc MuleSoft