Metodi HTTP e codifica URL (HTTP Request Response)
Come il client dice al server cosa vuole fare: i verbi HTTP, dove viaggiano i parametri e perché un indirizzo web non può contenere spazi o simboli a caso. Dal CRUD alla query string, fino al percent-encoding.
1. I metodi HTTP: i verbi del web
Un metodo HTTP (detto anche verbo) indica l'intenzione del client: dice al server che operazione vuole eseguire sulla risorsa identificata dall'URL. È la prima parola della request line: GET /index.html HTTP/1.1
In una comunicazione client-server, l'URL da solo non basta: /utenti/42 potrebbe voler dire “dammi l'utente 42” oppure “cancella l'utente 42”. A distinguerle è il metodo. Senza metodo, il server non sa se deve leggere, creare, aggiornare o eliminare.
Immagina l'app del registro: quando apri /assenze?data=2026-05-13 fai un GET (sei in lettura). Quando premi “Inserisci assenza” e invii il form, il browser fa POST. Quando il docente modifica l'assenza, frontend invia PUT su /assenze/123. Quando la annulla, invia DELETE.
Per ricordarti i verbi all'interrogazione, usa la frase: “Get legge, Post produce, PUT apposto, DELETE distrugge”. Suona sciocca, ma funziona al 100% in verifica.
2. CRUD ↔ HTTP: la mappa che devi ricordare
Le quattro operazioni fondamentali sui dati sono CRUD: Create, Read, Update, Delete. HTTP ha un verbo dedicato per ciascuna. In 5° ti bastano i 4 base, ma esistono anche PATCH (update parziale), HEAD, OPTIONS.
GET
Recupera una risorsa. Non deve modificare lo stato server. Idempotente e cacheable. È il 90% del traffico web.
POST
Crea una nuova risorsa subordinata. Non idempotente. Dati nel body. Es: registrazione, nuovo articolo.
PUT · DELETE
PUT sostituisce completamente una risorsa a URI noto. DELETE la rimuove. Entrambi idempotenti per definizione.
| Metodo | CRUD | Idempotente? | Descrizione operativa |
|---|---|---|---|
| GET | Read | Sì | Richiede pagina HTML, immagine, JSON API. Mai effetti collaterali previsti. |
| POST | Create | No | Invia dati per creare (nuovo utente). Il server decide l'URI finale e risponde 201. |
| PUT | Update (replace) | Sì | Carica/aggiorna risorsa a URI noto, sostituzione completa. |
| DELETE | Delete | Sì | Rimuove la risorsa a quell'URI. Se già cancellata, risposta uguale. |
Dire che “POST è sicuro perché nasconde i parametri”. Falso: POST li sposta nel body, ma senza HTTPS sono leggibili con DevTools o Wireshark. La sicurezza la dà HTTPS/TLS, non il verbo.
3. GET vs POST: dove viaggiano i parametri
Con GET i parametri sono nell'URL dopo il ? come nome=valore&nome2=valore2. Con POST sono nel body della richiesta HTTP, quindi non compaiono nella barra degli indirizzi, ma sono comunque ispezionabili.
Questo dettaglio cambia tutto: condivisibilità, cache, lunghezza massima, log del server, cronologia browser.
| Aspetto | GET (? nell'URL) | POST (nel body) |
|---|---|---|
| Visibilità URL | Sì, tutto in chiaro in barra | No, non in URL (ma visibile in DevTools Network) |
| Lunghezza | Limitata ~2000 char pratici | Virtualmente illimitata (limite server/php.ini) |
| Cache / Bookmark | Sì, cacheable e salvabile nei preferiti | No, non cacheable né linkabile |
| File upload | Impossibile | Sì, con multipart/form-data |
| Log e privacy | Parametri in log server e cronologia | Meno esposti, ma solo HTTPS li protegge davvero |
Form ricerca biblioteca: method="GET" così puoi copiare il link /cerca?titolo=TCP e mandarlo al compagno. Form login: method="POST" altrimenti password finirebbe nella cronologia del browser e nei log del proxy scolastico! Per questo i siti seri usano POST + HTTPS + HttpOnly cookie.
4. Struttura della query string
La query string è la parte dell'URL che inizia dopo il carattere ?. È composta da coppie chiave=valore separate da &. Se valore contiene caratteri speciali, va codificata altrimenti spacca il parsing.
L'ordine delle coppie di solito non conta per il server, ma conta per cache e firma HMAC. In JavaScript usa sempre URLSearchParams invece di concatenare stringhe a mano: evita 90% degli errori di codifica.
5. La codifica URL – percent-encoding
La codifica URL trasforma ogni carattere non sicuro in %XX dove XX è il codice ASCII in esadecimale. Negli URL sono permessi solo unreserved: A-Z a-z 0-9 - _ . ~ . Tutto il resto va codificato.
Senza codifica, un carattere come & verrebbe confuso con il separatore di parametri, lo spazio spezzerebbe l'URL, % stesso creerebbe ambiguità perché è il carattere di escape.
Originale: societa=Rossi & Martini → se la metti in URL così, il parser vede due parametri: societa=Rossi e Martini (senza valore). Codificata: societa=Rossi%20%26%20Martini → ora il server riceve esattamente “Rossi & Martini”. Lo spazio %20 e la & %26 non sono più separatori.
| Carattere | Codifica | Perché si codifica | Nota pratica |
|---|---|---|---|
| (spazio) | %20 o + | Spazio non ammesso in URL | In query string + = spazio (legacy form) |
| & | %26 | Separatore coppie | Se non codifichi, tronca la coppia |
| = | %3D | Assegnazione nome=valore | Ambiguità se nel valore |
| % | %25 | È il carattere di escape stesso | Va codificato per primo! |
| + | %2B | Potrebbe essere letto come spazio | Telefono +39 va %2B39 |
| @ / : ? # | %40 %2F %3A %3F %23 | Riservati in URI (path, query) | Codifica solo se compaiono nei valori |
Procedura di codifica corretta
- Identifica i caratteri non unreserved: tutto ciò che non è A-Z a-z 0-9 - _ . ~
- Converti ogni carattere in byte ASCII e poi in
%XXesadecimale maiuscolo (es. spazio 32 → 0x20 → %20) - Costruisci coppie con
encodeURIComponent(nome)=encodeURIComponent(valore)e uniscile con&
Se codifichi due volte: %20 → %2520 perché % diventa %25. Il server allora vede letteralmente “%20” e non uno spazio. Codifica una sola volta e solo i valori, non l'intera URL già pronta!
6. Form HTML, DevTools e Postman in pratica
In laboratorio lo vedi subito: un form con method GET crea una query string visibile. Con POST la vedi solo in DevTools → Network → Payload/Form Data.
Chrome F12 → Network
Filtra per Doc/Fetch/XHR, clicca la richiesta, leggi Method, Query String Parameters, Form Data e confronta GET vs POST reali.
POST con body
Crea POST a https://httpbin.org/post con body x-www-form-urlencoded contenente & e spazi. Postman codifica automaticamente, prova a disattivare.
HTTPS obbligatoria
GET e POST senza TLS mostrano tutto in Wireshark → Follow HTTP Stream. Con HTTPS vedi IP + SNI, ma non path, query o body.
Apri httpbin.org/get?citta=Roma Est&azienda=Rossi & Martini senza codifica: il server vede azienda=Rossi e un parametro vuoto Martini. Se codifichi ?azienda=Rossi%20%26%20Martini, il server riceve correttamente Rossi & Martini nel campo args.
7. Verifica / Esercizio
🔬 Attività — costruisci la richiesta giusta
Scenario: mini-app contatti scolastici con API: GET /api/contatti?q=...&citta=..., POST /api/contatti, PUT /api/contatti/{id}, DELETE /api/contatti/{id}. Dati test: cognome "De Luca", azienda "Rossi & Figli", città "L'Aquila", nota "Tel. +39 0862 123456".
- Scrivi URL completo per cercare “De Luca” a “L'Aquila” usando GET, con codifica corretta.
- Per creare un contatto con azienda “Rossi & Figli”, che metodo usi? Dove metti i dati e perché? Scrivi body x-www-form-urlencoded codificato.
- Spiega perché usare GET per il login è un errore (cita cache, log, cronologia, referer).
- Cosa succede se invii ?azienda=Rossi & Figli senza codifica? Quanti parametri vede il server?
- Con DevTools, fai POST a https://httpbin.org/post con i dati sopra. Quali header indicano che i dati sono nel body?
1) GET codificata: /api/contatti?q=De%20Luca&citta=L%27Aquila (spazio %20, apostrofo %27). Con URLSearchParams: q=De+Luca&citta=L%27Aquila è ok perché + = spazio in QS. Mai lasciare spazi veri.
2) POST per Create: POST su /api/contatti. Dati nel body perché è creazione di nuova risorsa subordinata e contiene speciali + lunghi. Body: nome=...&azienda=Rossi%20%26%20Figli&citta=L%27Aquila¬a=Tel.%20%2B39%200862%20123456 con Content-Type: application/x-www-form-urlencoded.
3) GET per login NO: URL /login?user=mario&pass=123 resta in cronologia browser, log proxy scolastico, header Referer se clicchi link esterno, può essere cacheato, bookmarkato e indicizzato. POST + HTTPS evita leak in URL (ma non da keylogger o shoulder surfing).
4) Senza codifica: ?azienda=Rossi & Figli → parser spacca su &. Server legge azienda=Rossi e poi parametro vuoto " Figli" (o " Figli="). Dati persi e bug difficile da trovare.
5) Header POST: method: POST, Content-Type: application/x-www-form-urlencoded, Content-Length, payload in Form Data. In Wireshark senza TLS → Follow TCP Stream mostra tutto chiaro.
8. Riepilogo e concetti chiave
📚 Prossimo passo — Il protocollo HTTP: struttura di request e response
Ora che sai cosa chiedi (metodo) e come passi i parametri, smontiamo la richiesta completa: request line, header, body e risposta con status code. Porta DevTools: leggeremo una richiesta vera byte per byte nella prossima lezione.