I metodi HTTP dichiarano la tua intenzione su una risorsa; gli status code sono la risposta codificata del server. Per i metodi contano due proprietà: safe (in sola lettura, senza side effect) e idempotent (ripeterlo produce lo stesso risultato — importante per i retry sicuri).
| Metodo | Scopo | Safe | Idempotent |
|---|
| GET | Leggere una risorsa | Yes | Yes |
| POST | Creare / avviare un'azione | No | No |
| PUT | Sostituire una risorsa | No | Yes |
| PATCH | Aggiornare parzialmente | No | No* |
| DELETE | Rimuovere una risorsa | No | Yes |
| HEAD | Come GET, solo header | Yes | Yes |
La distinzione sull'idempotency è pratica: poiché PUT e DELETE sono idempotent, un client può ritentarli in sicurezza dopo un timeout; ritentare un POST non-idempotent rischia di creare un duplicato (il classico bug del doppio addebito).
Gli status code sono raggruppati per la loro prima cifra:
1xx Informational request received, continuing (100 Continue, 101 Switching)
2xx Success it worked (200 OK, 201 Created, 204 No Content)
3xx Redirection go elsewhere (301 Moved, 304 Not Modified)
4xx Client error YOUR request is wrong (400, 401, 403, 404, 429)
5xx Server error the SERVER failed (500, 502, 503, 504)
La riga più importante è la separazione 4xx vs 5xx: 4xx significa che il client ha inviato qualcosa di sbagliato (input errato, non autenticato, non trovato) — ritentare senza modifiche non aiuterà; 5xx significa che il server ha fallito — ritentare (con backoff) potrebbe riuscire. Impara a memoria quelli di ogni giorno: 401 (non autenticato) vs 403 (autenticato ma non autorizzato), 404 (non trovato), 429 (rate limited), 500 (crash generico del server), 502/503/504 (bad gateway / non disponibile / gateway timeout — di solito un problema upstream o di sovraccarico).
Questi codici sono il contratto condiviso tra ogni client e server, quindi la padronanza qui è attesa da chiunque costruisca o consumi API. Chi conduce il colloquio sonda le distinzioni che rivelano una vera comprensione: 401 vs 403, PUT vs PATCH, e soprattutto l'idempotency, che governa direttamente se i retry sono sicuri — una preoccupazione centrale nei sistemi distribuiti e nei flussi di pagamento. Restituire lo status code giusto rende anche la tua API prevedibile e gestita correttamente da cache, proxy e librerie client, quindi questa conoscenza plasma un buon design delle API, non è solo nozionismo.
Una raccolta di domande di colloquio IT con risposte dettagliate — da Junior a Senior.
Dona