Metodi HTTP - GET VS POST | W3Docs

HTTP (Hypertext Transfer Protocol) è stato creato per fornire comunicazione tra client e server. Funziona secondo un modello richiesta-risposta: il client invia una richiesta che specifica un metodo HTTP (detto anche verbo HTTP), e il metodo indica al server che tipo di azione eseguire sulla risorsa di destinazione.

Un <form> HTML supporta nativamente solo due di questi metodi — GET e POST — tramite il suo attributo method. Ecco perché questi due sono quelli che la maggior parte degli sviluppatori HTML incontra per prima. Ma HTTP stesso definisce diversi altri metodi (PUT, PATCH, DELETE, HEAD, OPTIONS, CONNECT), che si utilizzano tramite JavaScript (fetch) o dal backend quando si costruiscono REST API.

Due Proprietà Chiave: Sicuro e Idempotente

Prima di esaminare i singoli metodi, due termini descrivono il comportamento di ciascuno. Sono usati in tutta questa pagina e nelle specifiche HTTP.

Sicuro — il metodo è di sola lettura. Non deve modificare lo stato del server. Il recupero di una pagina non dovrebbe mai creare, aggiornare o eliminare nulla. GET, HEAD e OPTIONS sono sicuri.
Idempotente — effettuare la stessa richiesta una o più volte ha lo stesso effetto sul server. Inviare un DELETE per una risorsa una volta, o cinque volte, lascia la risorsa eliminata in entrambi i casi. I metodi sicuri sono sempre idempotenti, ma un metodo può essere idempotente senza essere sicuro (ad esempio PUT e DELETE).

Ecco come si confrontano i metodi più comuni:

Metodo	Sicuro	Idempotente	Ha corpo della richiesta	Utilizzo tipico
GET	Sì	Sì	No	Recuperare una risorsa
HEAD	Sì	Sì	No	Recuperare solo le intestazioni
OPTIONS	Sì	Sì	No	Scoprire i metodi consentiti / preflight CORS
POST	No	No	Sì	Creare una risorsa o inviare dati
PUT	No	Sì	Sì	Sostituire / aggiornare una risorsa a un URL noto
PATCH	No	Non garantito	Sì	Applicare una modifica parziale
DELETE	No	Sì	Di solito no	Rimuovere una risorsa

Informazione

PATCH non è garantito essere idempotente. A seconda di come viene scritto il patch, può esserlo (ad esempio, "imposta status su active") oppure no (ad esempio, "incrementa il contatore di 1"). La specifica HTTP lascia questo all'implementazione.

Metodo GET

Il metodo GET richiede dati da una fonte specificata. È sicuro e idempotente: legge solo i dati e non modifica mai nulla sul server. Le richieste GET possono essere memorizzate nella cache e rimangono nella cronologia del browser. Possono anche essere aggiunte ai preferiti.

Non dovrebbe mai essere usato per dati sensibili, perché la stringa di query fa parte dell'URL (che viene registrato, memorizzato nella cache e aggiunto ai preferiti). Le richieste GET hanno limitazioni pratiche di lunghezza e devono essere usate solo per recuperare dati.

Pericolo

Le stringhe di query (coppie nome/valore) vengono inviate nell'URL della richiesta GET.

Esempio di un tipo di input text con il metodo get

<!DOCTYPE html>
<html>
  <head>
    <title>Title of the document</title>
  </head>
  <body>
    <form action="/form/submit" method="get">
      First name:
      <input type="text" name="username" placeholder="Your name" />
      <br />
      <br />
      <input type="submit" value="Submit" />
    </form>
  </body>
</html>

Provalo tu stesso »

Metodo POST

Il metodo POST invia dati da elaborare a una fonte specificata. Non è né sicuro né idempotente: può modificare lo stato del server, e inviare lo stesso modulo due volte di solito crea due record — ecco perché i browser ti avvisano prima di reinviare i dati POST. A differenza del metodo GET, le richieste POST non vengono mai memorizzate nella cache, non rimangono nella cronologia del browser e non possono essere aggiunte ai preferiti. Inoltre, le richieste POST non sono soggette a limitazioni di lunghezza dell'URL, anche se i server in genere applicano i propri limiti di dimensione del corpo.

Pericolo

Le stringhe di query (coppie nome/valore) vengono inviate nel corpo del messaggio HTTP della richiesta POST.

Esempio di un modulo con il metodo "post"

<!DOCTYPE html>
<html>
  <head>
    <title>Title of the document</title>
  </head>
  <body>
    <form action="/form/submit" method="post">
      First name:
      <input type="text" name="username" placeholder="Your name" />
      <br /><br />
      <input type="submit" value="Submit" />
    </form>
  </body>
</html>

Provalo tu stesso »

Confronto tra i Metodi GET e POST

Caratteristica	GET	POST
Pulsante Indietro/Ricarica	Innocuo	Il ricaricamento della pagina reinvierà i dati del modulo. Il browser deve avvisare che i dati verranno reinviati in questo caso.
Può essere aggiunto ai preferiti	Sì	No
Può essere memorizzato nella cache	Sì	No
Tipo di codifica	application/x-www-form-urlencoded	application/x-www-form-urlencoded o multipart/form-data
Cronologia	Rimane nella cronologia del browser.	Non rimane nella cronologia del browser.
Limitazioni della lunghezza dei dati	Durante l'invio dei dati, il metodo GET aggiunge i dati all'URL. La lunghezza dell'URL è limitata (lunghezza massima URL di 2048 caratteri).	Non ha limitazioni di lunghezza dell'URL, anche se i server in genere applicano limiti di dimensione del corpo.
Limitazione del tipo di dati	Principalmente caratteri ASCII, anche se UTF-8 è supportato tramite percent-encoding.	Non ha restrizioni. Sono consentiti anche dati binari.
Sicurezza	Meno sicuro di POST, poiché i dati inviati fanno parte dell'URL.	POST è più sicuro di GET, poiché i dati non sono visibili nell'URL o nella cronologia del browser. Tuttavia, entrambi trasmettono i dati in testo normale tramite HTTP e richiedono HTTPS per la sicurezza effettiva.
Visibilità	I dati sono visibili a tutti nell'URL.	Non mostra i dati nell'URL.

Nota L'elemento <form> HTML supporta nativamente solo GET e POST tramite il suo attributo method. Per usare PUT, PATCH o DELETE, di solito si invia la richiesta con JavaScript (fetch) o si lascia che il framework backend sovrascriva il metodo.

HEAD, OPTIONS e CONNECT

Oltre a GET e POST, HTTP definisce diversi altri metodi. Tre di essi sono descritti qui; i metodi orientati alle risorse PUT, PATCH e DELETE seguono nelle loro sezioni dedicate.

Metodo	Sicuro	Idempotente	Descrizione
HEAD	Sì	Sì	Identico a GET, ma il server restituisce solo le intestazioni HTTP, non il corpo della risposta.
OPTIONS	Sì	Sì	Chiede al server quali metodi e opzioni sono disponibili per una risorsa.
CONNECT	No	No	Stabilisce un tunnel verso il server, utilizzato dai proxy per HTTPS.

HEAD

HEAD funziona esattamente come GET ma il server omette il corpo e restituisce solo le intestazioni. Poiché è sicuro e idempotente, è ideale quando hai bisogno di metadati senza scaricare l'intera risorsa — ad esempio, per controllare il Content-Length di un file di grandi dimensioni prima di scaricarlo, o per verificare se un URL è ancora raggiungibile (il suo codice di stato) senza trasferirne il contenuto.

OPTIONS

OPTIONS chiede al server cosa permette per una risorsa. La risposta include di solito un'intestazione Allow che elenca i metodi supportati (ad esempio Allow: GET, POST, OPTIONS). Il suo utilizzo più importante nel mondo reale è la richiesta preflight CORS: prima che un browser invii un PUT, DELETE cross-origin, o una richiesta con intestazioni personalizzate, invia automaticamente una richiesta OPTIONS per confermare che il server consente la chiamata effettiva. Raramente si scrivono richieste OPTIONS a mano — il browser lo fa per te.

CONNECT

CONNECT indica a un server proxy di stabilire un tunnel TCP/IP trasparente verso la destinazione, più comunemente in modo che il traffico HTTPS cifrato possa passare attraverso il proxy senza essere letto. Viene utilizzato dall'infrastruttura piuttosto che dal codice applicativo, quindi non lo chiamerai quasi mai direttamente.

Metodo PUT

Il metodo PUT viene utilizzato principalmente per sostituire o aggiornare una risorsa. Il client invia l'URL della risorsa di destinazione insieme a un corpo della richiesta che contiene la rappresentazione completa e aggiornata di quella risorsa. PUT può anche creare una risorsa quando è il client (non il server) a decidere l'URL della risorsa.

PUT non è sicuro, perché cambia lo stato sul server, ma è idempotente: se si invia la stessa richiesta PUT due volte, la risorsa si trova esattamente nello stesso stato in cui si troverebbe dopo una sola richiesta — il corpo sostituisce completamente ciò che c'era.

L'esempio seguente chiede al server di memorizzare il corpo JSON fornito come risorsa in /users/42:

Metodi HTTP - Esempio di richiesta PUT

PUT /users/42 HTTP/1.1
Host: www.w3docs.com
Accept-Language: en-us
Connection: keep-alive
Content-Type: application/json
Content-Length: 54

{
  "name": "Jane Doe",
  "email": "[email protected]"
}

Dopo aver memorizzato il corpo, il server potrebbe rispondere in questo modo:

Metodi HTTP - Esempio di risposta PUT

HTTP/1.1 200 OK
Date: Mon, 15 Jun 2026 14:53:57 GMT
Content-Type: application/json
Content-Length: 54
Connection: keep-alive

{
  "name": "Jane Doe",
  "email": "[email protected]"
}

Metodo PATCH

Il metodo PATCH viene utilizzato per la modifica parziale di una risorsa. A differenza di PUT, non ha bisogno dell'intera risorsa — il corpo contiene solo le modifiche da applicare.

PATCH non è sicuro, e non è garantito essere idempotente: a seconda del formato del patch, potrebbe o meno produrre lo stesso risultato se ripetuto. Un patch come "imposta status su active" è idempotente, ma un patch come "aggiungi 1 a views" non lo è. Le collisioni tra due richieste PATCH possono essere pericolose, perché alcuni formati di patch si aspettano di applicare le modifiche da uno stato base condiviso; altrimenti la risorsa può essere corrotta.

L'esempio seguente modifica solo il campo email dell'utente, lasciando invariato ogni altro campo:

Metodi HTTP - Esempio di richiesta PATCH

PATCH /users/42 HTTP/1.1
Host: www.w3docs.com
Content-Type: application/json
Content-Length: 31

{ "email": "[email protected]" }

HTTP/1.1 200 OK
Date: Mon, 15 Jun 2026 14:53:57 GMT
Content-Type: application/json
Connection: keep-alive

Metodo DELETE

Come suggerisce il nome, questo metodo rimuove la risorsa identificata da un URL. DELETE non è sicuro ma è idempotente: una volta che una risorsa viene eliminata, richiamare DELETE la lascia eliminata — lo stato finale è lo stesso. (Le chiamate ripetute possono restituire un codice di stato diverso, come 404 Not Found al secondo tentativo, ma lo stato del server non cambia ulteriormente.)

L'esempio seguente chiede al server di eliminare l'utente in /users/42:

Esempio di richiesta DELETE

DELETE /users/42 HTTP/1.1
Host: www.w3docs.com
Accept-Language: en-us
Connection: keep-alive

Dopo aver eliminato la risorsa, il server risponde comunemente con 204 No Content — uno stato di successo che non porta alcun corpo di risposta:

Esempio di risposta DELETE

HTTP/1.1 204 No Content
Date: Mon, 15 Jun 2026 14:53:57 GMT
Connection: keep-alive

Una risposta 200 OK (opzionalmente con un corpo che descrive la risorsa eliminata) è anch'essa una risposta DELETE valida. Consulta i messaggi di stato HTTP per l'elenco completo dei codici di stato.