API REST : contrat, sécurité, production
Une bonne réponse sur REST montre que tu penses au contrat, aux erreurs et à ce qui se passe quand ça tourne mal en production.
À retenir
- GET lit, POST crée, PUT remplace, PATCH modifie, DELETE supprime.
- 2xx succès, 4xx faute du client, 5xx faute du serveur.
- GET, PUT et DELETE sont idempotents ; POST ne l'est pas.
- Valide toujours les entrées côté serveur.
- Pagination par curseur pour les grandes collections.
Concevoir les ressources
Des noms au pluriel, pas de verbes : /utilisateurs/42/commandes. Les filtres passent par la query string, jamais par le chemin.
Erreurs utiles
Renvoie un corps d'erreur structuré : code, message lisible et champ concerné. 401 = non authentifié, 403 = authentifié mais non autorisé, 422 = validation.
{ "code": "VALIDATION_ERROR",
"message": "Email invalide",
"field": "email" }En production
Limitation de débit, timeouts, retries avec backoff, journalisation corrélée et métriques. C'est ce qui distingue un profil junior d'un profil confirmé.
Pièges fréquents
- Renvoyer 200 avec une erreur dans le corps.
- Exposer des identifiants séquentiels sensibles.
- Faire confiance à la validation côté client.
Questions que le recruteur peut poser
- Quelle différence entre PUT et PATCH ?
- Qu'est-ce que l'idempotence ?
- Comment sécuriserais-tu cette API ?
À réviser ensuiteSQL et modélisation : l'essentiel →