I codici di stato HTTP sono raggruppati in cinque classi in base alla loro prima cifra, e scegliere quello giusto permette ai client di reagire correttamente senza fare il parsing del body.
2xx Success — the request worked
3xx Redirection — further action / resource moved
4xx Client error — the caller did something wrong
5xx Server error — the server failed
2xx
200 OK — successo generico (GET, PUT, PATCH).201 Created — è stata creata una risorsa (restituisci un header Location).202 Accepted — accettata per elaborazione asincrona, non ancora completata.204 No Content — successo senza body (comune per DELETE).4xx
400 Bad Request — sintassi malformata o input non valido.401 Unauthorized — non autenticato (credenziali assenti/non valide).403 Forbidden — autenticato ma non autorizzato.404 Not Found — la risorsa non esiste.409 Conflict — in conflitto con lo stato attuale (es. email duplicata).422 Unprocessable Entity — ben formata ma fallisce la validazione.429 Too Many Requests — rate limit superato.5xx
500 Internal Server Error — un guasto inatteso del server.503 Service Unavailable — temporaneamente inattivo/sovraccarico.POST /users → 201 Created
Location: /users/42
DELETE /users/42 → 204 No Content
GET /users/999 → 404 Not Found
{ "error": "user not found" }
La distinzione chiave che gli intervistatori sondano: 401 ("chi sei?") vs 403 ("so chi sei, ma no"), e 400 (sintassi errata) vs 422 (sintassi valida, dati non validi).
Gli status code sono il segnale primario in una risposta REST — client, proxy, monitoring e logica di retry si basano tutti su di essi, quindi indovinarli è essenziale per l'interoperabilità. Un fallimento comune è restituire 200 OK con un body { "error": ... }: costringe ogni client a fare il parsing del body per sapere se la chiamata è riuscita, rompe il tooling HTTP generico e nasconde i fallimenti al monitoring. Codici precisi guidano anche comportamenti automatici: un 429 o un 503 dice a un client ben costruito di fare back off e ritentare, mentre un 4xx dice "non ritentare, correggi la richiesta." Gli intervistatori usano questa domanda per verificare che tu capisca HTTP come un contratto anziché come un trasporto stupido, e che tu distingua correttamente le coppie sottili (401/403, 400/422) — un segno distintivo di chi ha costruito e consumato API reali.
Una raccolta di domande di colloquio IT con risposte dettagliate — da Junior a Senior.
Dona