Les status codes HTTP sont regroupés en cinq classes selon leur premier chiffre, et choisir le bon permet aux clients de réagir correctement sans analyser (parser) le body.
2xx Success — la requête a fonctionné
3xx Redirection — action supplémentaire / ressource déplacée
4xx Client error — l'appelant a fait quelque chose de mal
5xx Server error — le serveur a échoué
2xx
200 OK — succès général (GET, PUT, PATCH).201 Created — une ressource a été créée (retourner un header Location).202 Accepted — accepté pour un traitement asynchrone, pas encore terminé.204 No Content — succès sans body (courant pour DELETE).4xx
400 Bad Request — syntaxe malformée ou entrée invalide.401 Unauthorized — non authentifié (credentials absents/invalides).403 Forbidden — authentifié mais non autorisé.404 Not Found — la ressource n'existe pas.409 Conflict — en conflit avec l'état actuel (p. ex. email en doublon).422 Unprocessable Entity — bien formé mais échoue à la validation.429 Too Many Requests — débit limité (rate limited).5xx
500 Internal Server Error — une panne serveur inattendue.503 Service Unavailable — temporairement hors service/surchargé.POST /users → 201 Created
Location: /users/42
DELETE /users/42 → 204 No Content
GET /users/999 → 404 Not Found
{ "error": "user not found" }
La distinction clé que les recruteurs sondent : 401 (« qui êtes-vous ? ») vs 403 (« je vous connais, mais non »), et 400 (mauvaise syntaxe) vs 422 (syntaxe valide, données invalides).
Les status codes sont le signal principal d'une réponse REST — clients, proxies, monitoring et logique de retry s'appuient tous dessus, donc les choisir correctement est essentiel à l'interopérabilité. Une défaillance courante est de retourner 200 OK avec un body { "error": ... } : cela force chaque client à parser le body pour savoir si l'appel a réussi, casse l'outillage HTTP générique, et cache les échecs au monitoring. Des codes précis pilotent aussi un comportement automatique : un 429 ou 503 indique à un client bien conçu de ralentir et réessayer, tandis qu'un 4xx dit « ne réessaie pas, corrige la requête ». Les recruteurs utilisent cette question pour vérifier que vous comprenez HTTP comme un contrat plutôt qu'un transport idiot, et que vous distinguez correctement les paires subtiles (401/403, 400/422) — la marque de quelqu'un qui a construit et consommé de vraies API.
Une bibliothèque de questions d'entretien IT avec des réponses détaillées — du Junior au Senior.
Faire un don