# HTTP QUERY (RFC 10008): un metodo sicuro con un corpo per le ricerche complesse
Table of Contents
Chi lavora con le API web conosce un fastidio ricorrente. Quando una ricerca diventa complessa - molti filtri, elenchi di valori, condizioni annidate - non c’è un modo davvero pulito per esprimerla usando i metodi HTTP di sempre. A giugno 2026 l’IETF, l’organismo che cura gli standard tecnici di Internet, ha pubblicato la RFC 10008 e introdotto un nuovo metodo HTTP pensato proprio per questo caso: si chiama QUERY.
Il problema che QUERY vuole risolvere
Ogni richiesta HTTP ha un “metodo”, cioè un verbo che dice al server cosa si vuole fare. I più noti sono GET (leggere qualcosa) e POST (inviare dati, di solito per creare o modificare).
Chi progetta un’API di ricerca si trova davanti a un bivio poco comodo:
-
GET è il metodo giusto per leggere, ma i parametri viaggiano nella querystring, cioè la coda dell’indirizzo dopo il punto interrogativo (
?nome=valore&...). Gli indirizzi hanno però limiti di lunghezza pratici: server, proxy e browser possono troncare o rifiutare URL troppo lunghi. Inoltre l’indirizzo finisce quasi sempre nei log e nella cronologia. Esprimere un filtro articolato in una querystring diventa presto illeggibile e fragile. -
POST permette di allegare un body, cioè un corpo del messaggio dove mettere i dati veri e propri, in JSON o in altri formati. Molte API usano POST per le ricerche solo per poter sfruttare questo corpo. Il problema è che POST nasce per operazioni che cambiano qualcosa, e questo confonde chi sta nel mezzo.
Qui servono due termini, spiegati in parole semplici. Una richiesta si dice sicura (safe) quando è di sola lettura: non ci si aspetta che modifichi nulla sul server. Si dice idempotente quando ripeterla identica non cambia il risultato: mandarla una o dieci volte porta allo stesso stato. GET ha entrambe le proprietà; POST no. Per questo cache e proxy non possono ripetere una POST in automatico dopo un errore di rete, né conservarne la risposta con tranquillità: non sanno se quella richiesta ha “toccato” qualcosa.
Il risultato è una scelta tra due compromessi: GET pulito ma con la querystring che scoppia, oppure POST comodo ma semanticamente sbagliato per una semplice ricerca.
Cos’è il metodo QUERY
QUERY colma esattamente questo vuoto. La RFC 10008 lo descrive come una richiesta sicura e idempotente che porta con sé un contenuto che indica come deve essere elaborata dalla risorsa di destinazione, la quale risponde con il risultato di quell’elaborazione.
In pratica: è una richiesta di sola lettura come GET, ma con un corpo come POST. Il testo dello standard è netto sulle due proprietà. Sul fronte della sicurezza: il client “non richiede né si aspetta alcun cambiamento allo stato della risorsa”. Sull’idempotenza: le richieste QUERY “possono essere ritentate o ripetute quando serve, per esempio dopo un errore di connessione”.
Detto altrimenti, QUERY dà a chi progetta API la cosa che né GET né POST offrono da soli: una ricerca complessa, con un corpo strutturato, che resta ripetibile e memorizzabile in cache senza rischi.
GET, POST e QUERY a confronto
Un modo semplice per fissare le idee:
- GET - legge, senza corpo utile; i parametri stanno nell’URL, con i suoi limiti.
- POST - ha un corpo, ma non è né sicuro né idempotente: pensato per modificare.
- QUERY - ha un corpo ed è sicuro e idempotente: pensato per interrogare.
La differenza non è cosmetica. Rende esplicita al server, alle cache e ai proxy l’intenzione reale - “sto solo leggendo” - e sblocca comportamenti come la ripetizione automatica e la conservazione in cache che con POST sarebbero azzardati.
Come funziona, in concreto
Alcuni dettagli dello standard aiutano a capire come si userà.
Il tipo di contenuto è obbligatorio. Il corpo di una QUERY può essere in qualsiasi formato: JSON, un’espressione simile a SQL, un linguaggio di filtro proprietario. Proprio per questo il server deve sapere cosa sta ricevendo. La RFC prevede che il server rifiuti la richiesta se manca l’intestazione Content-Type o se non è coerente con il contenuto, e vieta di “indovinare” il formato dai dati (niente content sniffing). Una richiesta priva dell’indicazione del tipo va respinta con un codice 4xx, tipicamente 400.
C’è un modo per annunciare il supporto. Lo standard introduce una nuova intestazione di risposta, Accept-Query, con cui una risorsa può dichiarare che accetta QUERY e quali formati di query capisce. Un esempio dalla specifica: Accept-Query: "application/jsonpath", application/sql;charset="UTF-8". Serve a far scoprire ai client, in modo ordinato, che quella via è disponibile.
Le risposte possono andare in cache. È il vantaggio pratico più evidente, perché incide direttamente su il tempo di risposta percepito da chi naviga. La risposta a una QUERY è memorizzabile, ma con un’attenzione: la chiave di cache - l’identificativo con cui la risposta viene ritrovata - deve tenere conto del corpo della richiesta e dei suoi metadati, non solo dell’URL. Le cache possono normalizzare differenze irrilevanti del contenuto per riconoscere richieste equivalenti, ma solo ai fini della chiave, senza alterare la richiesta vera.
La risposta può indicare dove ritrovare il risultato. Il server può includere un’intestazione Content-Location che punta a una risorsa con il risultato dell’operazione (eventualmente temporanea), oppure Location per indicare una risorsa “equivalente”: un indirizzo su cui un client potrà poi fare una normale GET per ripetere la stessa interrogazione senza rimandare tutto il corpo.
Sicurezza e compatibilità: cosa tenere d’occhio
Ci sono aspetti pratici che conviene valutare prima di adottarlo.
Sul piano della riservatezza c’è un beneficio: spostando i criteri di ricerca dall’URL al corpo, i dati sensibili finiscono meno spesso nei log, perché - come nota la RFC - l’indirizzo viene registrato e trattato dagli intermediari molto più del contenuto. Lo standard raccomanda anche che, se il server crea una risorsa temporanea per il risultato, l’indirizzo assegnato non contenga parti sensibili della query originale.
Restano però attriti di adozione. Nei browser una QUERY verso un’altra origine richiede una richiesta di preflight CORS - un controllo preliminare che il browser fa per verificare i permessi - perché QUERY non è tra i metodi considerati “sicuri per impostazione predefinita”. Va inoltre ricordato che l’eccezione per cui un redirect trasforma una POST in GET (risposte 301 o 302) non si applica a QUERY. E, banalmente, ogni anello della catena - proxy, web server, framework, librerie client - deve imparare a riconoscere il nuovo metodo: finché non lo fa, una QUERY può essere bloccata o gestita male.
A che punto è la standardizzazione
Qui serve una precisazione, perché in giro si trova ancora la vecchia dizione. Per anni questa proposta è esistita come Internet-Draft con il nome draft-ietf-httpbis-safe-method-w-body, elaborata dal gruppo di lavoro httpbis dell’IETF, lo stesso che ha prodotto anche l’header per segnalare le API deprecate e lo schema di autenticazione concealed. Nel novembre 2025 il testo è stato approvato e a giugno 2026 è stato pubblicato come RFC 10008. Non è più quindi una semplice bozza: è un documento pubblicato.
Attenzione però al livello. RFC 10008 è uno Standard Proposto (Proposed Standard), cioè il primo gradino stabile della via degli standard IETF: un testo maturo, rivisto pubblicamente e citabile, ma non ancora il livello finale di “Internet Standard”. In termini pratici significa che la specifica è solida, mentre il supporto reale in server, proxy e framework è ancora in corso di diffusione.
Gli autori sono Julian Reschke (greenbytes), James M. Snell (Cloudflare) e Mike Bishop (Akamai). La presenza di Cloudflare e Akamai, due grandi operatori di rete e CDN, è un segnale utile: sono proprio gli attori che devono supportare il metodo lungo il percorso perché diventi usabile su larga scala, la stessa spinta con cui Cloudflare sta sperimentando anche su altri fronti del protocollo, per esempio un nuovo uso dello status HTTP 402 per il traffico dei crawler AI.
Perché può tornare utile a chi sviluppa API
Il valore di QUERY non è l’ennesima sigla, ma il fatto di dare un nome corretto a una cosa che si faceva già forzando gli strumenti. Chi finora ha usato POST per le ricerche lo ha fatto per un motivo tecnico legittimo - serviva un corpo - ma pagando in chiarezza e perdendo cache e ripetizione automatica.
In prospettiva, per un’API con ricerche articolate conviene valutare QUERY come alternativa più onesta: mantiene la semantica di lettura, evita i limiti dell’URL, tiene i criteri fuori dai log e riapre la porta alla cache. Nel frattempo, dato che l’adozione lungo la catena non è ancora universale, un approccio prudente è tenere una via di fallback su POST e verificare il comportamento di proxy e client prima di affidarsi solo a QUERY in produzione. È una di quelle novità che non cambiano tutto domani, ma che nel giro di qualche anno è ragionevole aspettarsi come opzione standard nelle API di ricerca.
