Indice dei contenuti dell'articolo:
Nel mondo HTTP siamo abituati da decenni a ragionare intorno a pochi metodi fondamentali. GET per recuperare una risorsa, POST per inviare dati al server, PUT per aggiornare, DELETE per eliminare. Su questa grammatica apparentemente semplice si regge una parte enorme del Web moderno: siti, API REST, applicazioni mobile, servizi SaaS, microservizi, reverse proxy, CDN e sistemi di caching.
Con l’evoluzione delle applicazioni, però, è emersa una zona grigia sempre più evidente: come gestire correttamente le query complesse di sola lettura? Pensiamo a una ricerca con molti filtri, a una richiesta GraphQL, a un endpoint di reportistica, a una consultazione con paginazione, ordinamenti, range temporali e condizioni annidate. Dal punto di vista semantico, l’operazione è una lettura: il server deve restituire dati, non modificarli. Quindi verrebbe naturale usare GET. Ma dal punto di vista pratico, GET costringe a mettere tutto nell’URL, con limiti di lunghezza, problemi di encoding, scarsa leggibilità e possibili implicazioni di privacy nei log.
Per anni la soluzione più comune è stata usare POST anche per operazioni che, in realtà, erano semplici interrogazioni. POST permette di inviare un corpo strutturato, ad esempio JSON, ma comunica al protocollo un significato diverso: una richiesta che potrebbe modificare lo stato del server. Questo dettaglio non è solo teorico. Per cache, proxy, CDN, WAF e client HTTP, il metodo utilizzato è un’informazione fondamentale. Usare POST per leggere dati significa spesso rinunciare a una parte delle ottimizzazioni che HTTP mette già a disposizione.
Il nuovo metodo HTTP QUERY, standardizzato con RFC 10008, nasce proprio per colmare questo vuoto: permette di inviare una richiesta con un corpo, come POST, ma mantiene le proprietà di una richiesta di sola lettura, come GET. In altre parole, QUERY dice al server e agli intermediari: “sto eseguendo una query, posso avere un body, ma non sto chiedendo di modificare lo stato della risorsa”.
Il problema storico: GET è corretto, ma spesso insufficiente
GET è il metodo HTTP più naturale quando vogliamo recuperare informazioni. È sicuro, perché il client non chiede al server di modificare lo stato della risorsa, ed è idempotente, perché ripetere la stessa richiesta più volte non dovrebbe produrre effetti collaterali differenti. Inoltre, le risposte a GET sono facilmente gestibili da cache, browser, reverse proxy e CDN.
Il problema nasce quando la query diventa troppo articolata. Una richiesta come questa è perfettamente gestibile:
GET /prodotti?categoria=hosting&limit=10&sort=prezzo HTTP/1.1 Host: example.com
Ma cosa succede quando i filtri diventano decine, magari con condizioni annidate, array, date, operatori logici, ricerca full-text, preferenze di ordinamento e parametri di aggregazione? L’URL diventa lungo, difficile da leggere e più fragile lungo tutta la catena di consegna. Browser, librerie client, proxy aziendali, bilanciatori, CDN e firewall applicativi possono avere limiti e comportamenti differenti.
C’è poi un tema spesso sottovalutato: gli URL vengono loggati molto facilmente. Finiscono nei log del web server, nei log dei reverse proxy, nella cronologia del browser, in strumenti di analytics, in sistemi di monitoraggio o in dashboard di debugging. Se la query contiene dati sensibili, anche indiretti, inserirli nella query string non è sempre la scelta più prudente.
Perché POST non è mai stato una soluzione elegante
POST risolve il problema pratico del body. Possiamo inviare un JSON complesso, una query GraphQL, un payload XML o un formato applicativo personalizzato senza dover comprimere tutto dentro l’URL. Per questo molte API moderne hanno usato POST anche per operazioni di sola lettura.
Il punto è che POST non comunica al protocollo la stessa semantica di GET. Una POST può creare una risorsa, aggiornare uno stato, avviare un processo, registrare un ordine, inviare un messaggio, produrre effetti permanenti. Quando la usiamo solo per interrogare dati, il server lo sa, il client applicativo magari lo sa, ma gli intermediari HTTP non possono dedurlo in modo generale.
Questo significa che cache, retry automatici, ottimizzazioni dei proxy e strategie CDN diventano più complicate. Un sistema intermedio non può assumere che ripetere una POST sia innocuo. Non può trattarla con la stessa disinvoltura con cui tratta una GET. Di conseguenza, molte API che eseguono letture pesanti finiscono per gravare sempre sul backend, anche quando la risposta sarebbe tecnicamente riutilizzabile.
Cosa introduce HTTP QUERY
QUERY introduce un concetto semplice ma molto potente: una richiesta può avere un corpo, ma restare una richiesta di sola lettura. La struttura è simile a POST, ma la semantica è diversa.
QUERY /api/search HTTP/1.1
Host: example.com
Content-Type: application/json
Accept: application/json
{
"q": "hosting linux managed",
"limit": 20,
"sort": "-created_at",
"filters": {
"status": "active",
"type": ["article", "service"]
}
}
Con QUERY, il contenuto della richiesta descrive come interrogare la risorsa target. Il server elabora la query e restituisce il risultato, senza che il client stia chiedendo una modifica dello stato della risorsa. La RFC definisce QUERY come metodo sicuro e idempotente: due proprietà decisive per chi progetta API affidabili, scalabili e correttamente integrabili con l’infrastruttura HTTP.
Non bisogna però confondere QUERY con un nuovo formato dati. QUERY non impone JSON, SQL, GraphQL o JSONPath. Il formato viene dichiarato tramite Content-Type. Questo rende il metodo flessibile: ogni applicazione può scegliere il linguaggio di query più adatto, purché client e server siano d’accordo sul significato del payload.
GET, POST e QUERY a confronto
| Proprietà | GET | POST | QUERY |
|---|---|---|---|
| Sicuro | Sì | Non necessariamente | Sì |
| Idempotente | Sì | Non necessariamente | Sì |
| Body nella richiesta | Nessuna semantica generale definita | Sì | Sì |
| Adatto a query complesse | Solo entro certi limiti pratici | Sì, ma con semantica ambigua | Sì, con semantica corretta |
| Cacheable | Sì | Con forti limitazioni pratiche | Sì |
La differenza principale è proprio questa: QUERY combina il body di POST con la semantica di GET. È un dettaglio che può sembrare sottile, ma per chi lavora su API ad alto traffico, architetture a microservizi o infrastrutture distribuite può fare una grande differenza.
Il ruolo dell’header Accept-Query
La RFC introduce anche l’header Accept-Query, pensato per permettere a una risorsa di dichiarare quali formati di query supporta. È un meccanismo di discovery utile perché evita al client di tirare a indovinare.
HTTP/1.1 200 OK Allow: GET, QUERY Accept-Query: application/json, application/graphql
In questo esempio, il server dichiara che la risorsa accetta richieste QUERY con payload JSON o GraphQL. Per un client ben progettato, questa informazione è preziosa: permette di scegliere il formato corretto, gestire fallback e produrre errori più chiari quando il formato non è supportato.
La presenza di Accept-Query è interessante anche dal punto di vista infrastrutturale. In un ambiente composto da API gateway, reverse proxy e servizi backend, poter dichiarare in modo esplicito il supporto ai formati di query aiuta a progettare contratti più puliti tra i vari componenti.
Cache e reverse proxy: dove QUERY diventa davvero interessante
Il valore pratico di QUERY emerge soprattutto quando parliamo di caching. Una richiesta GET viene normalmente identificata dall’URI. Con QUERY, invece, una cache deve considerare anche il contenuto della richiesta e i metadati rilevanti, come Content-Type e altri header che influiscono sul risultato.
Questo permette di avere più risposte cacheabili sullo stesso endpoint, distinguendole in base al body della query. Due richieste QUERY uguali possono essere servite dalla cache; due richieste QUERY diverse verso lo stesso endpoint devono produrre chiavi di cache diverse.
Per un’infrastruttura moderna, questo apre scenari interessanti:
- riduzione del carico applicativo su endpoint di ricerca o reportistica;
- migliore sfruttamento di reverse proxy e CDN davanti ad API di sola lettura;
- retry più sicuri in caso di errori temporanei di rete;
- semantica più chiara tra client, gateway e backend.
Naturalmente, non basta che il metodo sia standardizzato perché tutto funzioni immediatamente. Ogni elemento della catena deve riconoscerlo o almeno inoltrarlo correttamente: web server, proxy, bilanciatori, CDN, WAF, framework applicativi e librerie client.
Attenzione all’adozione: lo standard non significa supporto immediato
Un aspetto importante è distinguere tra standardizzazione e adozione reale. Il fatto che QUERY sia stato definito come RFC e registrato da IANA non significa che ogni browser, framework, CDN o firewall lo gestisca già in modo ottimale.
Nelle infrastrutture reali esistono spesso regole esplicite sui metodi HTTP ammessi. Un WAF può consentire solo GET, POST, HEAD, OPTIONS, PUT e DELETE. Un reverse proxy può avere configurazioni restrittive. Un’applicazione legacy può rispondere con errore a un metodo sconosciuto. Un sistema di logging può non classificare correttamente la nuova richiesta.
Per questo motivo, oggi QUERY va considerato come una tecnologia da valutare con attenzione, soprattutto in contesti controllati: comunicazioni server-to-server, API interne, ambienti di test, microservizi sotto lo stesso dominio operativo, endpoint di ricerca ad alto traffico dove client e server sono gestiti dalla stessa organizzazione.
Cosa significa per chi gestisce hosting, server Linux e API in produzione
Dal punto di vista sistemistico, QUERY non è solo una novità per sviluppatori. È un cambiamento che tocca anche chi gestisce l’infrastruttura. Se un’applicazione inizia a usare QUERY, bisogna verificare che tutta la catena sia pronta a ricevere e inoltrare correttamente il nuovo metodo.
In un ambiente Linux con web server, reverse proxy e firewall applicativi, le verifiche principali riguardano almeno questi aspetti: configurazioni di Nginx o Apache, regole del WAF, policy CORS, logging, metriche, sistemi APM, bilanciatori, CDN e strumenti di sicurezza. Un metodo HTTP sconosciuto o non esplicitamente permesso può essere bloccato prima ancora di raggiungere l’applicazione.
È importante anche ragionare sulla cache. Se un reverse proxy o una CDN inizia a cacheare risposte QUERY, la chiave di cache deve includere il contenuto della richiesta e i metadati corretti. Una normalizzazione errata potrebbe restituire risultati sbagliati. Al contrario, una configurazione troppo conservativa potrebbe annullare i benefici del nuovo metodo.
In altre parole, QUERY può essere molto utile, ma va inserito in un progetto infrastrutturale consapevole. Non è un semplice “cambio di verbo” lato codice: richiede test, osservabilità e regole coerenti su tutta la piattaforma.
Un esempio pratico con curl
Un client potrebbe inviare una richiesta QUERY in questo modo:
curl -X QUERY "https://api.example.com/search"
-H "Content-Type: application/json"
-H "Accept: application/json"
--data '{
"q": "server managed linux",
"limit": 10,
"sort": "-published_at"
}'
Dal punto di vista applicativo, il server riceve un payload strutturato. Dal punto di vista semantico, però, la richiesta non è una POST generica: è una interrogazione sicura e idempotente. Questo è il punto centrale dello standard.
QUERY sostituirà GET o POST?
No. QUERY non nasce per sostituire GET o POST, ma per coprire un caso d’uso che fino a oggi era gestito con compromessi. GET resta perfetto per richieste semplici, risorse direttamente identificabili da URL e contenuti facilmente cacheabili. POST resta il metodo corretto quando il client invia dati che possono creare, modificare o avviare un’elaborazione con effetti sul server.
QUERY si inserisce tra i due: è adatto quando dobbiamo eseguire una query complessa, con body, ma di sola lettura. È quindi particolarmente interessante per API di ricerca, GraphQL, endpoint di analytics, reportistica, aggregazioni e servizi interni che interrogano grandi quantità di dati senza modificarli.
Conclusione
HTTP QUERY è una novità importante perché corregge una stortura pratica che gli sviluppatori conoscono bene: usare GET quando la query non entra comodamente nell’URL, oppure usare POST perdendo chiarezza semantica e benefici infrastrutturali. Con QUERY, HTTP offre finalmente un metodo pensato per interrogazioni complesse, sicure, idempotenti e cacheabili.
Per chi sviluppa API, significa poter progettare endpoint più coerenti. Per chi gestisce infrastrutture Linux, reverse proxy, CDN e ambienti managed, significa prepararsi a supportare un nuovo metodo HTTP con configurazioni, test e policy adeguate.
Come spesso accade con gli standard, l’impatto non sarà immediato. L’adozione richiederà tempo, aggiornamenti e compatibilità lungo tutta la catena. Ma la direzione è chiara: QUERY rende HTTP più espressivo, più corretto e più adatto alle API moderne.
In Managed Server seguiamo con attenzione evoluzioni di questo tipo perché incidono direttamente su performance, sicurezza, caching e affidabilità delle applicazioni web. Un’infrastruttura ben gestita non si limita a “far girare” un sito o un’API: deve anche essere pronta ad adottare in modo sicuro e consapevole gli standard che migliorano il Web.
