Lo status code HTTP 204 (No Content) è una condizione da valutare con attenzione. Conosciamo già una serie di condizioni problematiche legate ai codici numerici che descrivono lo status di un portale: tutti quelli che rientrano nell’area 4XX si configurano come errori della pagina web (come il classico errore 404 o il 410 gone).
Mentre la famiglia dei 5XX riguarda errori del server: conosciamo bene i vari errori 502 bad gateway e 503. Ma sappiamo anche che il prefisso 2XX si configura come il recupero della pagina web andata a buon fine: perché ci dobbiamo preoccupare anche del codice status 204 No Content? Meglio approfondire l’argomento.
Noi sappiamo, come anticipato, che gli status code che rientrano sotto la voce del 2XX vengono considerate azioni andate a buon fine: la pagina esiste, l’infrastruttura IT funziona, il browser termina il lavoro. Questo è chiaro con il codice 200.
Il codice HTTP 204 No Content – che rientra nello standard HTTP/1.1 delineato in RFC 7231, Sezione 6.3.5. – è una risposta che il server invia quando ha processato con successo la richiesta, ma non ha nulla da restituire. In pratica, ti sta comunicando: “ok, tutto è andato bene ma non ho niente da mostrarti”. Il codice di stato 204 (nessun contenuto) indica che il server ha soddisfatto correttamente la richiesta e che, in modo intenzionale, non ci sono contenuti aggiuntivi da inviare nel corpo della risposta.
Da leggere: come gestire il file robots.txt
Dal punto di vista dell’utente, si tratta di un passaggio che non prevede il cambio della schermata: forse ti sarà capitato di inviare una richiesta al browser, aver aspettato il caricamento della risorsa ma non aver percepito alcun passaggio da una pagina web a un’altra. L’applicazione, quindi il browser, invia richiesta al server.
Il server la elabora e prepara la risposta: se quest’ultima non prevede alcun cambiamento – non ha contenuto nel body – il server stesso preferisce lo status code 204. Tutto è andato bene ma non c’è altro da comunicare.
Il client rimane sulla stessa pagina e l’utente non percepisce variazioni. Quindi, è importante ricordare che non si tratta di un errore o di una scelta che puoi fare in autonomia: è il server a decidere di puntare sull’HTTP 204.
Il codice di stato 204 (No Content) si usa quando una richiesta va a buon fine ma non c’è niente da restituire al client. Succede spesso nelle API: fai un’azione, il server la esegue correttamente, fine del processo.
Se aggiorni il profilo di un utente con una richiesta PUT e non ti serve ricevere indietro i dati aggiornati, il 204 è la risposta adeguata: tutto ok, non c’è altro da leggere perché il client magari ha già tutto. Alcuni esempi?
DELETE /api/tasks/123
→ 204 No Content (task cancellato, non serve altro)
GET /api/tasks/123
→ 200 OK + { "id": 123, "title": "..." } (ecco i dati)
PUT /api/tasks/123
→ 204 No Content (aggiornato, il client ha già i dati)
oppure
→ 200 OK + { "id": 123, "title": "..." } (aggiornato + ecco la versione finale)Stesso discorso quando elimini una risorsa con DELETE: l’elemento è stato cancellato, non ha senso mandare un messaggio di conferma o un JSON vuoto. Il server conferma che l’operazione è andata a buon fine. Anche il POST per azioni ha un senso quando premi un pulsante salva preferenze o segna come letto.
L’azione è completata, ma non serve una risposta con dati. In pratica, ogni volta che il client deve solo sapere che l’operazione è riuscita, e non deve usare nessun dato di risposta per aggiornare l’interfaccia o lo stato, il 204 No Content è la scelta giusta. Perché è chiaro, lineare, senza rumore inutile.
La differenza tra questi status code HTTP: in entrambi i casi l’azione va a buon fine ma nel 200 OK – lo status più comune per GET requests dove chiedi dei dati, li ricevi – la richiesta è riuscita ti sto restituendo dei dati. Quindi, il body della risposta contiene qualcosa, probabilmente del codice HTML ma non per forza.
Nel 204 No Content la richiesta è riuscita ma non c’è niente. Il body è vuoto ed è più efficiente quando non servono dati di ritorno: risparmi banda e segnala al client che non c’è errore, non devi aspettarti nulla.
Da leggere: come funziona l’FTP e a cosa serve
L’uso di uno status code corretto, al momento giusto, è già di per sé un vantaggio in termini di coerenza strutturale. Poi, con il 204 abbiamo un risparmio di banda che può essere più o meno importante perché non invii un body. Però se stavi per mandare un JSON tipo {"success": true} di 17 bytes, il risparmio è minimo.
Hosting gestito: veloce, affidabile, performante
Diventa utile se eviti di restituire oggetti grossi che il client ignorerebbe. Anche le performance lato server possono avere dei vantaggi ma sempre su situazioni in cui si presentano realtà ad altissimo traffico con milioni di richieste al secondo. La banda risparmiata? Onestamente, nella maggior parte dei casi è trascurabile rispetto ad altri colli di bottiglia. Il vantaggio vero: resta la chiarezza del contratto tra client e server.
