HTTP QUERY: il primo metodo nuovo in 16 anni (RFC 10008)

Risposta diretta: a giugno 2026 l'IETF ha pubblicato RFC 10008, che standardizza il metodo QUERY: è sicuro e idempotente come GET, ma può portare un body come POST, ed è cacheabile con la chiave di cache che include il contenuto della richiesta. È il primo metodo HTTP davvero nuovo dal PATCH (RFC 5789, marzo 2010): sedici anni. E no, non lo userai la settimana prossima — il supporto di server, proxy e client è ancora quasi inesistente.

TL;DR

QUERY = GET con un body. Safe, idempotente, cacheabile, ripetibile senza effetti collaterali.
Risolve un problema vero: ricerche complesse che non stanno in una URL e che oggi sei costretto a mandare in POST, perdendo caching e retry sicuri.
RFC 10008, giugno 2026, Standards Track. Autori: Julian Reschke (greenbytes), James M. Snell (Cloudflare), Mike Bishop (Akamai).
Due dettagli che cambiano l'architettura: la cache key include il body, e QUERY non è CORS-safelisted (dal browser paghi sempre il preflight).
Verdetto: progettalo, non deployarlo. L'adozione realistica è 2027-2028.

Il problema che QUERY risolve davvero

Se hai mai costruito un'API di ricerca seria, conosci il bivio. Hai una query complessa — filtri annidati, array di ID, un geo-polygon, una lista di facet — e devi scegliere:

Vai di GET e infili tutto nella query string. Funziona finché non sbatti contro il limite di lunghezza delle URL: lo standard non lo fissa, ma nella pratica i server si fermano intorno agli 8.000 caratteri (e alcuni proxy molto prima). In più ogni parametro finisce nei log del web server, nella cronologia del browser, nell'header Referer e nei sistemi di monitoring di mezzo. Se in quei filtri c'è un'email o un codice fiscale, l'hai appena sparso in cinque posti diversi.

Vai di POST e il problema di dimensione sparisce, ma perdi tre cose in un colpo: il caching (POST è cacheabile solo in teoria, nella pratica nessuno lo fa), l'idempotenza (un proxy o un client non sa se può ritentare senza combinare danni) e la semantica (stai dicendo al mondo "questa richiesta modifica lo stato", quando in realtà stai solo leggendo).

Da vent'anni la risposta a questo bivio è "usa POST e non pensarci". QUERY è il modo di smettere di mentire al protocollo.

GET vs POST vs QUERY

Caratteristica	GET	POST	QUERY
Sicuro (non muta stato)	Sì	No	Sì
Idempotente	Sì	No	Sì
Body nella richiesta	No	Sì	Sì
Cacheabile	Sì	In teoria, mai in pratica	Sì (key = body)
Ritentabile in automatico	Sì	Rischioso	Sì
Dati sensibili nell'URL	Sì, purtroppo	No	No

Che aspetto ha una richiesta QUERY

QUERY /orders HTTP/1.1
Host: api.example.org
Content-Type: application/x-www-form-urlencoded
Accept: application/json

select=surname,givenname,email&limit=10&match="email=*@example.*"

Il formato del body non è imposto dalla RFC: sono il Content-Type e il media type a definire cosa significa quella query. Puoi mandare JSON, SQL-like, GraphQL, CQL, quello che il tuo server capisce. Il server deve rifiutare richieste senza Content-Type o con metadati incoerenti.

Per farsi trovare, un server annuncia il supporto con il response header Accept-Query, che elenca i media type accettati per quel resource. È il meccanismo di discovery: prima di provare a mandare un QUERY, un client evoluto sa già se ha senso.

I due dettagli che ti cambiano l'architettura

1. La chiave di cache include il body

Questa è la parte interessante e la più insidiosa. La RFC dice che la risposta a un QUERY è cacheabile e che la cache key DEVE incorporare il contenuto della richiesta. Sulla carta è meraviglioso: finalmente puoi mettere una CDN davanti a una ricerca complessa.

Nella pratica significa che ogni intermediario deve fare hashing del body e — se vuole essere efficiente — normalizzarlo: due JSON identici con le chiavi in ordine diverso sono la stessa query, ma byte diversi. La RFC lo permette (normalizzazione content-encoding o specifica per formato) e nelle Security Considerations avverte del rovescio: una cache che normalizza male restituisce la risposta sbagliata a qualcun altro. Un bug di cache poisoning silenzioso, con dati di un altro utente. È esattamente il tipo di cosa che rende prudenti.

2. Dal browser paghi sempre il preflight

QUERY non è un metodo CORS-safelisted. Tradotto: qualunque fetch() cross-origin con metodo QUERY fa scattare una richiesta OPTIONS di preflight prima di quella vera. Due round-trip invece di uno, e un Access-Control-Allow-Methods da configurare correttamente. Nulla di drammatico, ma se stai valutando QUERY per il frontend mettilo nel conto.

E la parte che a me piace di più: la query diventa una URL

C'è un pezzo di RFC 10008 che passa inosservato e che invece è il vero regalo. Il server può rispondere con un header Location che assegna una URI a quella specifica query. Da quel momento la ricerca complessa che hai appena fatto ha un indirizzo: la puoi salvare nei preferiti, mandarla a un collega, richiamarla ogni notte con un cron per vedere come sono cambiati i risultati.

È la cosa che con POST non hai mai potuto avere e con GET non hai mai potuto permetterti. Con codici 301 o 308 il server può anche dirti che quella query "vive" stabilmente altrove.

Lo userei oggi in produzione?

No. E te lo dico da uno a cui gli standard nuovi piacciono parecchio.

Il supporto reale è agli inizi: pochi server applicativi implementano QUERY nativamente, i middleware e i framework lo trattano come metodo sconosciuto, e soprattutto l'infrastruttura in mezzo — load balancer aziendali, WAF, proxy, API gateway legacy — tende a bloccare o riscrivere i verbi che non conosce. Il collo di bottiglia dell'adozione non sarà il tuo backend: saranno i tre hop che non controlli. La stima ragionevole che gira nella community è 2027-2028 per un supporto abbastanza diffuso da poterci contare.

Nel frattempo, la mossa sensata è quella che consiglierei a qualunque team con cui lavoro:

Progetta le API di ricerca come se QUERY esistesse già. Endpoint dedicato, query dichiarativa nel body, nessun effetto collaterale, risultati deterministici.
Esponi oggi quell'endpoint come POST, ma trattalo internamente come safe e idempotente: niente scritture, niente contatori, niente side effect.
Quando l'infrastruttura sarà pronta, aggiungere il verbo QUERY sarà una riga di routing, non un refactoring.

È lo stesso principio per cui vale la pena avere disciplina anche quando nessuno la premia subito: il costo si paga dopo, e si paga di più.

FAQ

QUERY sostituisce GET?

No. GET resta il metodo per recuperare una risorsa identificata dalla sua URL, ed è insostituibile per tutto ciò che deve essere linkabile e cacheabile in modo banale. QUERY serve quando la richiesta è troppo grande, troppo strutturata o troppo sensibile per stare in una URL.

Posso già usarlo con fetch() nel browser?

Tecnicamente fetch('/orders', { method: 'QUERY', body }) è una chiamata valida, ma il server dall'altra parte deve capirla e il browser farà un preflight CORS se l'origine è diversa. Finché non c'è supporto lato server e lungo la catena di proxy, resta un esperimento da laboratorio.

Perché ci sono voluti 16 anni per un metodo nuovo?

Perché aggiungere un verbo a HTTP significa convincere browser, server, CDN, proxy, firewall e miliardi di righe di codice esistente. PATCH (2010) ci ha messo anni a diventare normale. QUERY parte con lo stesso problema: la specifica è la parte facile, l'ecosistema è quella difficile.

QUERY è più sicuro di GET?

Per i dati sensibili sì, e la RFC lo dice esplicitamente: le URI vengono loggate e processate dagli intermediari molto più del contenuto della richiesta. Spostare i filtri dal query string al body li toglie da log, cronologia e Referer. Non è cifratura — è solo smettere di scriverli in chiaro in cinque posti.

Se stai progettando o rifacendo le API di un prodotto e vuoi che reggano i prossimi cinque anni (standard nuovi inclusi), parliamone — è buona parte di quello che faccio come Fractional CTO.