Quali sono le principali differenze tra i metodi di richiesta HTTP GET e POST?

Scopo

• GET richiede una rappresentazione di una risorsa. Per specifica è di sola lettura: il client non si aspetta alcun cambiamento dello stato del server. RFC 9110 nota che l'invio di un corpo in una richiesta GET ha una semantica non definita, quindi GET non dovrebbe contenere un corpo.
• POST chiede alla risorsa di destinazione di elaborare i dati racchiusi nel corpo della richiesta secondo la semantica propria di quella risorsa (creare un record, inviare un modulo, caricare un file, ecc.).

Dove vanno i dati

• GET trasporta i parametri nella stringa di query dell'URL (dopo ?, formattata come key=value&...). Questi sono visibili nella barra degli indirizzi e registrati nella cronologia del browser e nei registri del server e sono vincolati da un pratico limite di lunghezza dell'URL.
• POST trasporta i dati nel corpo della richiesta; il tipo è dato dall'intestazione Content-Type. I moduli HTML in genere utilizzano application/x-www-form-urlencoded (predefinito) o multipart/form-data (per i file). Non esiste un limite di dimensione fisso a livello di protocollo, ma server e proxy configurano i propri limiti massimi (ad esempio Nginx client_max_body_size).

Proprietà secondo RFC 9110

• Sicuro: GET è sicuro (sola lettura); Il POST non lo è.
• Idempotente: una richiesta è idempotente se effettuarla N volte ha lo stesso effetto sullo stato del server di effettuarla una volta. GET è idempotente; POST non lo è: ripeterlo può creare duplicati, come due ordini identici. Idempotente non è la stessa cosa di sicuro (PUT e DELETE sono idempotenti ma non sicuri) e non dice nulla sul fatto che il corpo della risposta sia identico.
• Memorizzabile nella cache: le risposte GET sono memorizzabili nella cache per impostazione predefinita; Le risposte POST possono essere memorizzate nella cache solo quando includono informazioni esplicite sull'aggiornamento e un'intestazione Content-Location corrispondente, cosa rara nella pratica.

Implicazioni pratiche

• Utilizzare GET per il recupero e la navigazione; i risultati possono essere ripetuti, aggiunti ai segnalibri e precaricati in modo sicuro e l'aggiornamento di una pagina GET è innocuo.
• Utilizza POST per azioni di modifica dello stato e per l'invio di payload sensibili o di grandi dimensioni. L'aggiornamento o il ritorno a una pagina POST attiva l'avviso "conferma reinvio modulo" del browser.
• Non inviare mai password tramite GET: finirebbero nell'URL, nei registri e nella cronologia. Questa è igiene, non crittografia: HTTPS crittografa sia l'URL che il corpo in transito, ma l'URL viene comunque registrato.

Follow-up comuni

• I metodi sicuri sono GET, HEAD, OPTIONS; i metodi idempotenti sono GET, HEAD, PUT, DELETE; POST non è nessuno dei due.
• Entrambi i metodi sono supportati dai moduli HTML (l'attributo method).
• "Sicuro" nel senso RFC significa nessun cambiamento di stato, non protezione dei dati.
• L'idempotenza POST a livello di applicazione viene spesso applicata utilizzando chiavi di idempotenza.