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.
2 lames sur 4 viennent de la même enseigne —Les Juges, le verdict.
Le tirage — 4 lames
La lecture
API design
Le contrat complet : routes, schémas, erreurs, authentification, pagination.
happydouanière des contrats d'API
audit securite
Les failles cherchées avant la mise en ligne, pas après l’incident.
serruriereserrurière des portes du bastion
tests de bout en bout
Les parcours joués en entier, comme un vrai client les jouerait.
funambulefunambule des parcours sans filet
api budget
Le coût par appel, et le point où il faut mettre un cache.
metreusemétreuse des factures cloud
À la fin : Une API dont le contrat est écrit et vérifié.
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 parscripts/parcours/check-parcours.sh : chaque lame citée existe dans le registre du framework.