Il nuovo metodo HTTP QUERY (RFC 10008): Cos’è e perché colma il vuoto tra GET e POST

Pubblicato da

   

Per anni, chi ha progettato API web si è trovato di fronte a un compromesso frustrante: quando si trattava di recuperare dati complessi, il sistema tradizionale mostrava i suoi limiti. Con la pubblicazione ufficiale dell'RFC 10008 da parte dell'IETF (l'organismo che definisce gli standard di internet), è stato introdotto un nuovo metodo HTTP ufficiale: QUERY.

Questo articolo analizza nel dettaglio che cos'è questo metodo, chiarisce cosa significa "idempotenza" senza giri di parole, fa il punto sullo stato dell'arte e mostra differenze ed esempi pratici rispetto al classico POST.

🔗 Ti piace Techelopment? Dai un'occhiata al sito per tutti i dettagli!

1. Il problema: Il vuoto tra GET e POST

Prima dell'introduzione di QUERY, le opzioni per interrogare un server erano essenzialmente due, entrambe imperfette per determinate situazioni:

  • GET (Il metodo sicuro e cacheable, ma senza corpo): È ideale per leggere dati, può essere messo in cache e ripeterlo è sicuro. Tuttavia, non supporta un request body (un corpo della richiesta). Tutti i parametri devono passare nell'URL (la query string). Questo crea enormi problemi quando si devono inviare filtri complessi, strutture JSON nidificate o query molto lunghe, poiché gli URL hanno limiti di lunghezza pratici (imposti da browser o server).
  • POST (Il metodo con il corpo, ma non sicuro): Permette di inviare qualsiasi mole di dati nel corpo della richiesta. Il problema è che POST nasce semanticamente per modificare lo stato del server (creare risorse, effettuare pagamenti, registrare utenti). Di conseguenza, i POST non sono idempotenti e non possono essere messi in cache dai browser o dai proxy intermedi in modo sicuro. Ripetere un POST per errore (es. a causa di un timeout di rete) potrebbe significare duplicare un'operazione o alterare i dati.

La soluzione: QUERY

Il metodo QUERY unisce il meglio dei due mondi: prende la struttura a corpo (body-carrying) del POST e la combina con la sicurezza e l'idempotenza del GET.


2. Cosa significa esattamente "Idempotente" e "Sicuro"?

Molti articoli tecnici usano questi termini dando per scontato che tutti li conoscano. Semplifichiamo al massimo:

  • Sicuro (Safe): Significa che la richiesta non modifica lo stato del server. Quando fai una richiesta QUERY, stai semplicemente chiedendo al server: "Leggimi dei dati elaborando questi criteri". Il database non viene alterato, non vengono creati record e non vengono inviate email. È un'operazione di sola lettura logica.
  • Idempotente (Idempotent): Significa che eseguire la stessa richiesta una volta o cento volte consecutive produce esattamente lo stesso identico effetto sul server. Poiché la richiesta non cambia lo stato, ripeterla all'infinito non comporterà effetti collaterali indesiderati.

Perché l'idempotenza è fondamentale?

Grazie al fatto che QUERY è idempotente e sicuro, i client di rete, i load balancer e le CDN (Content Delivery Network) possono riprovare automaticamente una richiesta fallita (ad esempio se cade la connessione) senza temere di causare danni o alterazioni. Inoltre, a differenza del POST, le risposte a un metodo QUERY possono essere memorizzate in cache, migliorando drasticamente le performance delle API.


3. Stato dell'arte: Può essere già usato?

La risposta è: Sì, ma con le dovute cautele infrastrutturali.

  • Standardizzazione: L'RFC 10008 è ufficialmente un Proposed Standard dell'IETF. Non è più una bozza teorica, ma uno standard ratificato.
  • Supporto nei linguaggi e backend: Molti ecosistemi si sono mossi rapidamente. Ambienti come Node.js (nel modulo http) e Go (grazie alla flessibilità di net/http) supportano nativamente o gestiscono senza problemi i metodi custom come QUERY. Framework di backend moderni (ad esempio in .NET 10 o ecosistemi simili) stanno integrando il supporto out-of-the-box.
  • Il collo di bottiglia (Browser e Middleware): Allo stato attuale, nessun browser maggiore implementa nativamente l'invio di un metodo QUERY tramite JavaScript fetch/axios (di solito si ripiega ancora su POST o GET). Inoltre, i vecchi Web Application Firewall (WAF), i proxy inversi o i filtri di sicurezza aziendali potrebbero non riconoscere ancora il verbo QUERY, scambiandolo per un errore o bloccandolo se non aggiornati.

4. Esempi pratici: POST vs QUERY a confronto

Immagina di dover sviluppare un sistema di e-commerce in cui l'utente può filtrare un catalogo immenso di prodotti usando criteri avanzati espressi in JSON (categorie, range di prezzo, attributi dinamici multipli).

Approccio tradizionale con POST

Storicamente, per aggirare il limite di lunghezza della stringa di query di un GET, gli sviluppatori usavano un POST mascherato da ricerca:

POST /api/products/search HTTP/1.1
Host: api.store.com
Content-Type: application/json

{
  "category": "elettronica",
  "price_range": { "min": 100, "max": 500 },
  "tags": ["wireless", "bluetooth"],
  "sort": "popularity"
}

I problemi di questo approccio:

  1. Niente Cache: Poiché il metodo è un POST, nessuna cache intermedia (come Cloudflare o il browser) salverà il risultato. Ogni singola ricerca identica ripeterà il calcolo pesante sul database.
  2. Nessun Retry Automatico: Se la connessione cade mentre la richiesta POST è in transito, il client non sa se il server ha ricevuto il dato ed è rischioso ripeterla automaticamente.
  3. Semantica errata: Stai dicendo al server di "creare o elaborare qualcosa" (POST), mentre tu vuoi solo "leggere" dei dati filtrati.

Il nuovo approccio con QUERY

Ecco come cambia la stessa identica chiamata adottando lo standard QUERY (RFC 10008):

QUERY /api/products HTTP/1.1
Host: api.store.com
Content-Type: application/json
Accept: application/json

{
  "category": "elettronica",
  "price_range": { "min": 100, "max": 500 },
  "tags": ["wireless", "bluetooth"],
  "sort": "popularity"
}

I vantaggi immediati:

  1. Cache Abilitata: La risposta del server può essere memorizzata in cache in modo sicuro, proprio come farebbe un GET, alleggerendo enormemente il database per ricerche frequenti.
  2. Idempotenza e Sicurezza: Se la rete tentenna, il client sa che può ripetere la richiesta QUERY tutte le volte che vuole senza correre il rischio di alterare lo stato del sistema.
  3. Separazione pulita delle responsabilità: L'URI (/api/products) identifica la risorsa principale, mentre il corpo della richiesta definisce la vista filtrata che si desidera ottenere, senza inquinare l'URL con parametri illeggibili o troppo lunghi.

Inoltre, lo standard introduce header dedicati come Accept-Query per permettere al server di dichiarare quali formati di query supporta, rendendo la negoziazione dei contenuti estremamente pulita.


5. Conclusioni

Il metodo HTTP QUERY non è un semplice vezzo stilistico, ma la risoluzione formale di un'anomalia architetturale che durava da decenni nel protocollo HTTP.

Anche se l'adozione lato browser e proxy richiederà tempo per completarsi, comprendere e integrare QUERY nelle proprie API server-to-server o nei backend moderni rappresenta il passo fondamentale per scrivere codice più pulito, performante e semanticamente corretto.



Follow me #techelopment

Official site: www.techelopment.it
facebook: Techelopment
instagram: @techelopment
X: techelopment
Bluesky: @techelopment
telegram: @techelopment_channel
whatsapp: Techelopment
youtube: @techelopment