HTTP cambia dopo oltre 30 anni: arriva QUERY, il nuovo metodo che affianca GET e POST

Ogni volta che apriamo una pagina web, utilizziamo un’applicazione cloud o interroghiamo un’API, entra in gioco HTTP, il protocollo che da oltre 30 anni regola lo scambio di informazioni tra client e server. Nato all’inizio degli anni ’90 insieme al World Wide Web ideato da Tim Berners-Lee, HTTP si è evoluto più volte, passando dalle semplici richieste di documenti HTML alle comunicazioni ad alte prestazioni che oggi alimentano servizi di streaming, piattaforme SaaS (Software-as-a-Service), applicazioni mobili e infrastrutture distribuite su scala globale.

Con la pubblicazione di RFC 10008, l’Internet Engineering Task Force (IETF) introduce ufficialmente il metodo HTTP QUERY, una novità che punta a colmare una lacuna rimasta aperta sin dagli albori di HTTP.

Come funziona HTTP, in breve

Il funzionamento di HTTP si basa su un modello relativamente semplice: il client invia una richiesta al server e riceve una risposta.

All’interno della richiesta, però, non conta soltanto quale risorsa si desidera raggiungere; conta anche l’azione che si intende eseguire. Per questo motivo HTTP definisce una serie di metodi, spesso chiamati anche “verbi HTTP“, che descrivono l’operazione richiesta. GET recupera informazioni; POST trasmette dati al server; PUT aggiorna una risorsa esistente; DELETE ne richiede la rimozione. Nel tempo la famiglia dei metodi si è ampliata per rispondere a esigenze sempre più specifiche.

Gran parte del traffico generato dalle applicazioni moderne consiste in semplici operazioni di lettura. Un browser richiede una pagina Web, un’app mobile recupera dati da un servizio remoto, un software aziendale interroga un database tramite API.

In tutti questi casi il client invia una richiesta e il server restituisce informazioni senza modificare necessariamente alcun dato. Tradizionalmente il metodo GET rappresenta lo strumento ideale per questo genere di operazioni: i parametri sono inseriti direttamente nell’URL e il server produce la risposta corrispondente.

Utilizzo dei metodi GET e POST

Con l’aumento della complessità lato API, però, questo modello ha iniziato a mostrare alcuni limiti. Molte interrogazioni moderne richiedono filtri avanzati, strutture JSON annidate, condizioni multiple, criteri di ordinamento e grandi quantità di parametri. Inserire tutte queste informazioni nell’URL può risultare scomodo e, in alcuni casi, incompatibile con le restrizioni imposte da browser, proxy e dispositivi intermedi. Per aggirare il problema, numerosi sviluppatori hanno iniziato a utilizzare POST anche per semplici richieste di lettura, sfruttando il corpo della richiesta per trasportare dati più complessi.

Il fatto è che POST nasce per operazioni che possono modificare lo stato del server. Quando il metodo è utilizzato solo per eseguire ricerche o interrogazioni, la semantica del protocollo perde parte della sua chiarezza. Cache, proxy e altri componenti dell’infrastruttura HTTP non possono più distinguere facilmente una semplice ricerca da un’operazione che produce modifiche permanenti.

È proprio questa lacuna, discussa da anni all’interno della comunità IETF, che ha portato alla definizione di RFC 10008 e all’introduzione del nuovo metodo QUERY citato in apertura.

Cos’è e a cosa serve il nuovo metodo QUERY

La specifica dell’IETF definisce QUERY come un metodo HTTP sicuro che invia i parametri della richiesta nel corpo del messaggio, anziché includerli nell’URI (l’indirizzo della risorsa richiesta). Il suo funzionamento è molto simile a quello di POST, ma con una differenza essenziale: QUERY indica esplicitamente che l’operazione è di sola lettura e non comporta modifiche permanenti ai dati o allo stato del server.

Il metodo QUERY utilizza il corpo della richiesta come avviene con POST, ma specifica formalmente che l’operazione è sicura, cioè non modifica i dati sul server, e idempotente, ovvero produce sempre lo stesso risultato quando eseguita più volte nelle stesse condizioni. In pratica, il client può inviare query complesse senza inserire i dati nell’URL e senza perdere le proprietà tipiche delle richieste di sola lettura.

La differenza può sembrare sottile, ma per browser, proxy, CDN e sistemi di caching rappresenta un’informazione estremamente importante. Finalmente il protocollo dispone di un metodo dedicato alle interrogazioni complesse che non modificano alcuna risorsa.

Proprietà	GET	QUERY	POST
Sicura	Sì	Sì	Potenzialmente no
Idempotente	Sì	Sì	Potenzialmente no
URI per la query	Sì, per definizione	Opzionale, tramite header Location	No
URI per il risultato della query	Opzionale, tramite header Content-Location	Opzionale, tramite header Content-Location	Opzionale, tramite header Content-Location
Cacheable	Sì	Sì	Sì, ma solo per future richieste GET o HEAD
Content/body della richiesta	Nessuna semantica definita	Previsto, con semantica definita dalla risorsa target	Previsto, con semantica definita dalla risorsa target

Implicazioni per cache, proxy e infrastrutture web

Poiché il metodo QYERY dichiara formalmente il proprio comportamento sicuro, sistemi intermedi e componenti di caching possono adottare politiche più efficienti. In teoria diventa possibile riutilizzare risultati già elaborati e ridurre il carico sui server applicativi.

Va detto però che l’efficacia pratica dipenderà dall’adozione da parte di browser, CDN, reverse proxy e framework Web: l’introduzione di un nuovo metodo HTTP non produce benefici immediati se gli elementi della catena di comunicazione non lo riconoscono correttamente.

Alcuni software potrebbero inizialmente trattare QUERY come un metodo sconosciuto: in tali casi sarà necessario aggiornare configurazioni, regole firewall e meccanismi di instradamento per garantire la completa compatibilità.