Aller au contenu principal
- HTTP et serveurs : un contrat requête/réponse explicite (statuts 200/201/204/400/401/403/404/409/422/429/500, erreurs Problem Details avec
traceId), timeouts, limitation de débit et arrêt gracieux.
- REST : ressources nommées (pas des actions),
Location sur 201, concurrence par ETag/If-Match (412), pagination par curseur {created_at, id}, idempotence par Idempotency-Key, versionnage seulement sur rupture de contrat.
- Authentification : frontières de menace (navigateur, réseau, origine), Argon2 salé, sessions serveur en cookies
HttpOnly/Secure/SameSite, rotation d’ID anti-fixation, JWT avec iss/aud/alg validés et révocation, CSRF par double-submit.
- Persistance : modélisation (users, sessions, posts), migrations numérotées immuables, index composites selon « égalité → plage → tri », isolation adaptée à la zone critique, contrôle optimiste par version, backups testés.
- Tests et observabilité : pyramide pragmatique (unitaires, intégration, contrats, E2E, perf), base de tests éphémère, logs JSON corrélés par
traceId, métriques (taux d’erreur, p50/p95/p99, débit, saturation).
- Un
500 sans traceId est une investigation à l’aveugle ; un Problem Details avec traceId est une recherche dans les logs.
403 sur une ressource privée confirme son existence ; 404 la protège.- Un token dans
localStorage est volable par la moindre XSS ; un cookie HttpOnly ne l’est pas.
If-Match + 412 rendent au client la résolution de conflit ; l’API reste simple.- Une migration appliquée est immuable : on corrige par une nouvelle migration.
- Un test qui n’a jamais échoué ne prouve rien (prouvez le rouge au moins une fois).
- La p99 qui grimpe sans la p50 pointe des requêtes lentes, pas une saturation globale.
- Une sauvegarde non restaurée n’existe pas : chronométrez la restauration.
- Flow : Client → API → DB → réponse 201 + cookie, pour raconter le fil rouge
POST /signup d’une traite.
- Séquences : timeouts et arrêt gracieux (Proxy/API) ; mise à jour conditionnelle ETag ; rotation de refresh tokens ; traçage d’une requête vers l’observabilité.
- Interactifs : cycle requête-réponse (
HttpLifecycleVisualizer), cache HTTP HIT/MISS/304, explorateur d’en-têtes, limiteur token bucket, arrêt gracieux, CORS, retry avec jitter.
- Schéma simple de base : trois tables reliées (
users 1-n sessions, users 1-n posts) avec l’index composite (author_id, created_at DESC) annoté.
- Se souvenir / Comprendre : statuts HTTP, anomalies d’isolation, frontières XSS/CSRF/fixation.
- Appliquer : écrire un Problem Details, un cookie de session sécurisé, un index composite, un triplet de tests.
- Analyser : lire un
EXPLAIN, choisir 404 vs 403, diagnostiquer p50 vs p99.
- Évaluer : sessions serveur vs JWT selon le contexte, migration en deux temps pour un
DROP COLUMN.
- Créer : assembler le
POST /signup complet du mini-atelier (validation, Argon2, cookie, 409, test de contrat).
- Prérequis : reseaux-web/http.mdx (protocole), bases-sql/select.mdx et bases-sql/join.mdx (SQL élémentaire).
- Approfondissements : securite-appliquee/auth-web.mdx (attaques web en detail), bases-sql/transactions.mdx (isolation avancee), systemes-distribues/idempotence-exactly-once.mdx (retries et doubles ecritures).
- Suite logique : devops-cloud/observabilite.mdx (metriques et alertes en production), projet-synthese/index.mdx (projet final).