HTTP QUERY: il metodo che chiude finalmente il buco tra GET e POST

Il metodo HTTP che mancava tra GET e POST: sicuro, idempotente, cacheable, con un corpo nella richiesta. Dalla proposta alla standardizzazione IETF.

Chiunque abbia costruito una API di ricerca conosce questo dilemma. Vuoi esporre un endpoint per query complesse: filtri multipli, ordinamenti, un’espressione GraphQL, magari una query SQL-like. La prima idea è usare GET, che è il metodo corretto dal punto di vista semantico: sei sicuro, sei idempotente, sei cacheable. Ma GET non ha un corpo definito, quindi tutta quella complessità deve finire nell’URI, sotto forma di query string. Funziona finché i parametri sono pochi. Poi arrivano i limiti di lunghezza (diversi e imprevedibili a seconda di client, proxy e CDN), l’encoding di strutture annidate diventa illeggibile, e i dati sensibili finiscono loggati e bookmarkabili in chiaro nell’URL.

Allora la maggior parte degli sviluppatori arrende le armi e usa POST. Funziona: il corpo può contenere qualunque struttura. Ma POST non è né sicuro né idempotente: un intermediario non può assumere che ripetere la richiesta sia innocuo, quindi niente cache automatica, niente retry sicuri, niente ottimizzazioni dei CDN. È esattamente la scelta che hanno fatto GraphQL, gRPC-over-HTTP, SOAP e XML-RPC per anni: usare POST anche per operazioni di sola lettura, pagando il prezzo in termini di caching e semantica.

Per anni questo è stato un compromesso accettato. Il 19 giugno 2026 ha smesso di esserlo: l’IETF ha pubblicato RFC 10008, “The HTTP QUERY Method”, come Proposed Standard. Vediamo da dove arriva questa proposta, come funziona nel dettaglio, e cosa significa per chi progetta API oggi.

Il nuovo metodo HTTP QUERY apre un varco tra i due sentieri battuti finora, GET e POST.

Da dove nasce la proposta

L’idea di un metodo HTTP sicuro con un corpo nella richiesta non è nuova: WebDAV lo faceva già nel 2003 con SEARCH (RFC 5323), e prima ancora con PROPFIND e REPORT. Il problema di quei metodi è che portano con sé tutto il bagaglio semantico di WebDAV, pensato per un namespace molto specifico (gestione di risorse e proprietà), e non si generalizzano bene al resto del web.

La proposta di un metodo generico, pensato esplicitamente per colmare il divario tra GET e POST su tutto HTTP, circola nella comunità HTTP Working Group da diversi anni: le prime discussioni pubbliche risalgono almeno al 2021, quando il draft iniziale (poi diventato draft-ietf-httpbis-safe-method-w-body) cominciò a girare tra gli sviluppatori. Da lì è passato attraverso numerose revisioni, quattordici versioni del draft, discussioni sulla mailing list dell’HTTPbis Working Group e più round di Last Call, fino ad arrivare, nel giugno 2026, alla pubblicazione ufficiale come RFC.

Gli autori, tre nomi con un peso specifico non da poco nell’ecosistema HTTP, sono Julian Reschke (greenbytes, storicamente co-editor delle specifiche HTTP/1.1), James M. Snell (Cloudflare) e Mike Bishop (Akamai). Il documento è stato sponsorizzato dal gruppo di lavoro HTTPbis dell’IETF, con Gorry Fairhurst come Area Director responsabile.

Un dettaglio che gli autori chiariscono esplicitamente nel documento: il nome scelto è “QUERY” e non uno dei metodi WebDAV esistenti (SEARCH, REPORT, PROPFIND) proprio per evitare l’ambiguità semantica di quei metodi e catturare meglio il legame concettuale con il query component di un URI, generalizzando il pattern a qualunque tipo di risorsa, non solo a WebDAV.

Il problema che risolve davvero

Il nodo centrale, che RFC 10008 mette nero su bianco nell’introduzione, è che nessuno dei due metodi classici copre bene il caso delle query di sola lettura ma complesse.

I limiti di GET:

• i limiti di lunghezza dell’URI non sono chiari né uniformi: variano da client a client, da proxy a proxy, da CDN a CDN, e superarli produce errori difficili da diagnosticare;
• alcune strutture dati sono scomode o impossibili da codificare correttamente in un URI (nesting profondo, binari, testo libero lungo);
• gli URI delle richieste finiscono più facilmente loggati, salvati nella cronologia del browser o bookmarkati, esponendo dati che magari non dovrebbero comparire in chiaro in un log.

I limiti di POST:

• non è sicuro né idempotente, quindi un client o un intermediario non possono ripetere automaticamente la richiesta in caso di errore di rete senza rischiare effetti collaterali;
• non è cacheable per default, il che complica parecchio il lavoro di CDN e reverse proxy davanti ad API che, di fatto, restituiscono sempre dati di sola lettura;
• da un punto di vista semantico è ambiguo: un client non può dedurre dal solo metodo se una POST crea, modifica, elimina o semplicemente legge qualcosa.

QUERY prende il corpo di POST e la sicurezza/idempotenza di GET, restando anche cacheable: la combinazione che, di fatto, GraphQL e affini stavano cercando di simulare da anni usando POST come workaround.

Come funziona in pratica

Una richiesta QUERY assomiglia a una POST, ma con la garanzia esplicita che il server non altererà lo stato della risorsa target. Il Content-Type è obbligatorio, perché definisce il formato in cui è espressa la query: può essere JSON, un formato applicativo come application/graphql, un formato di query strutturato come application/jsonpath, o anche testo semplice.

Un esempio con una query GraphQL:

QUERY /api/graphql HTTP/1.1
Content-Type: application/graphql

{ users(role: "admin") { id name email } }

Un esempio con un filtro di ricerca strutturato in JSON:

QUERY /feed HTTP/1.1
Content-Type: application/json

{
   "q": "distributed systems",
   "limit": 10,
   "sort": "-published",
   "filters": ["status:active", "type:post"]
}

E un esempio più vicino a un’interrogazione stile SQL, con risposta in CSV:

QUERY /contacts HTTP/1.1
Host: example.org
Content-Type: example/query
Accept: text/csv

select surname, givenname, email limit 10

Se il server non capisce o non accetta il Content-Type inviato, risponde con codici di errore precisi: 400 Bad Request se l’header manca o è incoerente, 415 Unsupported Media Type se il formato non è supportato, 422 Unprocessable Content se la sintassi è valida ma la query non è processabile, 406 Not Acceptable se non riesce a produrre una risposta nel formato richiesto dall’Accept del client.

L’header Accept-Query

RFC 10008 introduce anche un nuovo header di risposta, Accept-Query, con cui una risorsa dichiara sia il supporto al metodo QUERY sia i formati di query che accetta, usando la sintassi degli Structured Field Values (RFC 9651):

HTTP/1.1 200 OK
Allow: GET, QUERY
Accept-Query: application/json, application/graphql

Cache, condizioni e redirect

Qui sta buona parte del valore pratico del metodo. La chiave di cache di una risposta QUERY include, oltre all’URI target, anche il contenuto della richiesta e i metadati rilevanti: due query diverse sullo stesso endpoint producono voci di cache distinte, ma query identiche possono essere servite dalla cache senza toccare il backend.

QUERY supporta anche le richieste condizionali, esattamente come GET: un client può inviare If-None-Match con un ETag e ricevere 304 Not Modified se il risultato non è cambiato, oppure usare If-Modified-Since, If-Match, If-Unmodified-Since e persino le range request.

Per collegare la risposta a una risorsa concreta e riutilizzabile, il server ha tre strade:

1. includere un header Content-Location che punta a una risorsa scaricabile con una successiva GET;
2. includere un header Location per query ripetibili in futuro;
3. rispondere con un redirect 303 See Other verso un URI raggiungibile via GET.

E qui c’è una differenza interessante rispetto al comportamento classico dei redirect: QUERY preserva il proprio metodo attraverso i redirect 301, 302, 307 e 308 (un client che segue quei redirect ripete una QUERY, non la trasforma in GET). Solo il 303 converte esplicitamente la richiesta successiva in GET, che è proprio il meccanismo pensato per “materializzare” il risultato di una query come risorsa autonoma.

Un dettaglio da tenere presente per chi lavora con API pubbliche esposte al browser: QUERY non è CORS-safelisted, quindi le richieste cross-origin richiedono un preflight OPTIONS, esattamente come già succede oggi per molte richieste POST con Content-Type non semplice.

A che punto siamo con l’adozione

Pubblicare un RFC come Proposed Standard non significa che il giorno dopo tutto l’ecosistema lo supporti. È il primo gradino della standards track IETF: la specifica è stabile e pronta per l’implementazione, ma serve tempo perché browser, server, proxy, CDN e librerie client la adottino davvero.

Allo stato attuale, nessun browser maggiore implementa QUERY in modo nativo. Sul lato server la situazione si muove più in fretta: Node.js ha aggiunto supporto al metodo nel proprio modulo http già durante la fase di draft, e Go, grazie al modo in cui net/http è progettato, supporta di fatto qualunque metodo custom (incluso QUERY) tramite http.NewRequest, senza bisogno di modifiche alla libreria standard. Subito dopo la pubblicazione dell’RFC, community di framework come Ruby on Rails hanno aperto discussioni pubbliche per valutare un supporto nativo.

Un caso rilevante per chi legge questo blog: anche DMVCFramework, il framework REST/MVC di riferimento per Delphi, ha già uno studio in corso per valutare e progettare il supporto al metodo QUERY. Se vuoi seguire da vicino queste decisioni tecniche, discuterne o proporre casi d’uso concreti, il posto giusto è il Patreon di DMVCFramework: è lì che condivido in anteprima il lavoro su queste funzionalità prima che diventino pubbliche.

Il pattern che ci si aspetta è quello già visto con altri metodi ed header HTTP diventati standard negli ultimi vent’anni: prima l’adozione lato server e nei tool di sviluppo, poi il consolidamento nei framework, infine, più lentamente, il supporto nativo dei browser e delle API JavaScript come fetch(). Nel frattempo, chi vuole sperimentare può già farlo lato server: HTTP, a livello di protocollo di trasporto, non ha mai impedito metodi custom, quindi implementare un endpoint che risponde a QUERY oggi è già possibile con la maggior parte degli stack server-side, a patto di gestire client, proxy intermedi e CDN che potrebbero non conoscere ancora il metodo e comportarsi in modo imprevedibile.

Cosa significa per chi progetta API

Per chi lavora oggi su API REST o su endpoint stile GraphQL, QUERY non è un’urgenza, ma è un metodo da tenere d’occhio con attenzione, perché risolve un problema reale e diffuso senza introdurre un nuovo formato o protocollo, solo un tassello mancante di HTTP. Alcune considerazioni pratiche:

• Non è (ancora) il momento di sostituire il traffico di produzione. Con zero browser che lo supportano nativamente, qualunque uso reale oggi passa da client HTTP custom o da librerie server-to-server, non da un form o da una fetch() in un browser generico.
• È un candidato naturale per endpoint interni o server-to-server. Se controlli sia il client sia il server, ad esempio in una architettura a microservizi, puoi già oggi ottenere semantica corretta e caching su query complesse senza aspettare il supporto dei browser.
• Semplifica il design delle API di ricerca e delle API GraphQL. Invece di forzare POST per operazioni di sola lettura, QUERY offre finalmente un modo semanticamente corretto di esprimere “sto leggendo, con una query complessa, e questa richiesta è sicura da ripetere e da mettere in cache”.
• Non serve reinventare nulla lato infrastruttura. Essendo semplicemente un nuovo metodo HTTP, tutta l’infrastruttura esistente basata su header standard (cache, ETag, redirect, content negotiation) continua a funzionare, a patto che i vari intermediari nel percorso lo riconoscano correttamente.
• Il colloquio tra un client Delphi e un server DMVCFramework. Un caso molto concreto per chi lavora con Delphi: un’applicazione desktop (VCL o FMX), un servizio Windows o un altro server, scritto in Delphi o in qualunque altro linguaggio, che deve interrogare un backend DMVCFramework con filtri di ricerca articolati (più campi, range di date, ordinamenti, paginazione). Oggi la scelta è tra un GET con query string scomoda da costruire e potenzialmente troppo lunga, o una POST che rinuncia a caching e idempotenza solo per “far stare” il filtro nel corpo. Con QUERY, quel client può inviare il filtro come corpo strutturato (tipicamente JSON) verso l’endpoint DMVCFramework, ottenendo semantica corretta, retry sicuri in caso di errore di rete, e la possibilità reale di sfruttare cache e reverse proxy davanti al server, cosa che con POST oggi non è possibile.

Punti chiave

• Il vuoto tra GET e POST ora ha un nome. QUERY combina il corpo di POST con la sicurezza e l’idempotenza di GET, restando anche cacheable.
• È realtà, non più solo una proposta. RFC 10008, “The HTTP QUERY Method”, è stato pubblicato dall’IETF come Proposed Standard il 19 giugno 2026.
• Non nasce dal nulla. Si ispira concettualmente a SEARCH di WebDAV (RFC 5323, 2003) ma generalizza il pattern a tutto il web con un nome nuovo e nessun bagaglio WebDAV.
• Ha una sintassi precisa. Content-Type obbligatorio, nuovo header Accept-Query per dichiarare i formati supportati, codici di errore dedicati (400, 415, 422, 406).
• Preserva la cache e la sicurezza di HTTP. Chiave di cache basata su contenuto e URI, richieste condizionali, redirect che preservano il metodo (tranne il 303).
• L’adozione è agli inizi. Nessun browser nativo ancora, ma Node.js e Go lo supportano già lato server, e framework come Ruby on Rails e DMVCFramework (per Delphi) stanno valutando l’adozione.

Domande frequenti

Cos’è il metodo HTTP QUERY?

QUERY è un nuovo metodo HTTP, standardizzato come RFC 10008, che permette di inviare una richiesta con un corpo (come POST) ma con semantica sicura e idempotente (come GET). Il server elabora il contenuto della richiesta e risponde con il risultato, senza modificare lo stato della risorsa target.

In cosa differisce da GET e POST?

GET è sicuro e idempotente ma non ha un corpo definito, quindi le query complesse finiscono nell’URI con limiti di lunghezza ed encoding scomodo. POST accetta un corpo ma non è né sicuro né idempotente, quindi non è cacheable e non può essere ripetuto automaticamente in sicurezza. QUERY prende il corpo da POST e la sicurezza/idempotenza da GET, restando anche cacheable.

Il metodo QUERY è stato accettato ufficialmente?

Sì. Il 19 giugno 2026 l’IETF ha pubblicato RFC 10008, “The HTTP QUERY Method”, come Proposed Standard, cioè il primo gradino della standards track IETF. Gli autori sono Julian Reschke, James M. Snell e Mike Bishop, prodotto dal gruppo di lavoro HTTPbis. Il metodo è ora registrato nell’IANA HTTP Method Registry come safe e idempotent.

I browser e i framework supportano già QUERY?

Il supporto è ancora agli inizi. Nessun browser maggiore lo implementa nativamente al momento della pubblicazione dell’RFC. Node.js ha aggiunto supporto lato server nel proprio modulo http, Go lo supporta già come qualsiasi metodo custom tramite http.NewRequest, e community come quella di Ruby on Rails hanno aperto discussioni per aggiungerlo subito dopo la pubblicazione della RFC. Ci si aspetta un’adozione progressiva nei prossimi mesi/anni, non immediata.

Perché non riusare metodi WebDAV come SEARCH, REPORT o PROPFIND?

Perché portano con sé il bagaglio semantico di WebDAV (RFC 5323, RFC 3253, RFC 4918), pensato per uno spazio dei nomi molto specifico, e non catturano bene il legame concettuale con il query component di un URI. Gli autori dell’RFC 10008 hanno scelto un nome nuovo, QUERY, proprio per evitare quell’ambiguità e generalizzare il pattern all’intero web.

DMVCFramework supporterà il metodo QUERY?

È già in corso uno studio per valutare e progettare il supporto al metodo QUERY in DMVCFramework, il framework REST/MVC per Delphi. Chi vuole seguire da vicino questo lavoro, discuterne o proporre casi d’uso può iscriversi al Patreon di DMVCFramework.

Fonti e approfondimenti: IETF, RFC 10008, “The HTTP QUERY Method” (giugno 2026); IETF Datatracker, pagina di tracciamento del documento; http.dev/query; kmcd.dev, “The HTTP Query Method”; Anton Oko, “HTTP QUERY: A New Method For Search Queries” su Medium; Dan Horovits, “HTTP’s New Method for Data APIs: HTTP QUERY” su Medium; discussione su Hacker News.