Je veux
faire une API que d’autres vont utiliser
Le contrat d’abord : ce que l’API promet, ce qu’elle refuse, comment elle s’authentifie. Le code vient après, et les tests avec.
À la fin
Une API dont le contrat est écrit et vérifié.
Les phrases, dans l’ordre
Copiez une phrase, laissez l’étape rendre ce qui est nommé, puis passez à la suivante.
API design
Le contrat complet : routes, schémas, erreurs, authentification, pagination.
Sous le capot
Happydouanière des contrats d'API
audit securite
Les failles cherchées avant la mise en ligne, pas après l’incident.
Sous le capot
Serruriereserrurière des portes du bastion
tests de bout en bout
Les parcours joués en entier, comme un vrai client les jouerait.
Sous le capot
Funambulefunambule des parcours sans filet
api budget
Le coût par appel, et le point où il faut mettre un cache.
Sous le capot
Metreusemétreuse des factures cloud
Sous le capot — 4 cartes
Si ce n’est pas tout à fait ça
- Je veux faire un produit en ligne payantLe chemin long : décider quoi construire, choisir la stack, écrire le contrat d’API, estimer la facture avant de la recevoir, déployer.
- Je veux vérifier que rien ne fuitDeux passes complémentaires : les failles applicatives, et les secrets écrits en dur qui partiront avec le prochain commit.
- Je veux mettre des tests là où il n’y en a pasTrois étages : les pièces isolées, les parcours entiers, et l’œil qui compare les rendus d’une version à l’autre.
Tirage écrit à la main dans data/parcours.json, tenu par scripts/parcours/check-parcours.sh : chaque carte citée existe dans le registre du framework.