Le ricerche web più complesse hanno finalmente un metodo HTTP dedicato. La Internet Engineering Task Force ha pubblicato QUERY, definito nella RFC 10008, affiancandolo ai più familiari GET, POST, PUT e PATCH. In sviluppo dal 2021, il nuovo metodo permette a un client di inviare richieste articolate attraverso un corpo dedicato, senza attribuire loro le implicazioni operative di POST.
Il punto centrale è l’idempotenza: una richiesta produce lo stesso effetto previsto sia quando viene inviata una volta, sia quando viene ripetuta. QUERY è inoltre definito come metodo sicuro, perché non chiede al server di modificare lo stato della risorsa interrogata. Client e intermediari possono quindi memorizzare le risposte e ritentare una richiesta dopo un’interruzione, senza rischiare di ripetere un’operazione come un addebito.
Finora le interrogazioni sono state gestite soprattutto con GET, caricando i parametri direttamente nell’URL. Il sistema funziona per ricerche semplici, ma filtri annidati, ordinamenti, intervalli temporali e altre istruzioni possono produrre indirizzi molto lunghi. HTTP raccomanda il supporto per URI di almeno 8.000 ottetti, ma non esiste un limite massimo universale: uno dei sistemi attraversati dalla richiesta può quindi respingere un URL sovradimensionato.
Gli URL carichi di parametri presentano anche un problema di esposizione dei dati, perché le informazioni possono finire nella cronologia del browser, nei log dei server o nei segnalibri. Per aggirare questi limiti, gli sviluppatori hanno trasferito per anni i payload complessi, spesso codificati in JSON, nel corpo delle richieste POST. Molte API hanno adottato questa soluzione e GraphQL, pur supportando GET, usa comunemente POST per le query.
Si tratta però di un adattamento estraneo alla funzione originaria di POST, associato anche all’invio di moduli, al caricamento di file e alla creazione o modifica di risorse. HTTP non considera POST sicuro o idempotente per impostazione predefinita. Proxy, gateway e browser non possono dunque presumere che una risposta sia riutilizzabile o che una richiesta fallita possa essere ritentata automaticamente, rendendo necessario l’intervento dell’applicazione o dell’utente.
QUERY combina il corpo della richiesta tipico di POST con una semantica esplicitamente di sola lettura. Per lo sviluppatore Elie Treport, il risultato apre la strada a una cache HTTP funzionale anche per richieste complesse: proxy, CDN e browser possono memorizzare richieste dotate di un corpo, con ricadute dirette sulle prestazioni. La RFC è stata scritta con il contributo di ingegneri di Cloudflare e Akamai, operatori attivi nella cache distribuita, insieme alla società tedesca greenbytes.
L’adozione resta la parte più impegnativa. Lo standard dei moduli HTML riconosce ancora soltanto GET e POST per l’invio ordinario e dovrà essere aggiornato prima del supporto nativo dei browser, un’attività già affrontata dal Web Hypertext Application Technology Working Group. Anche reverse proxy, bilanciatori di carico, CDN, gateway API, firewall e framework web potrebbero respingere QUERY come metodo sconosciuto finché non riceveranno gli aggiornamenti necessari.
I primi movimenti sono già visibili: Node.js sta aggiungendo il supporto nel proprio modulo HTTP, mentre Go e Laravel possono rispettivamente inviare metodi personalizzati e acquisire richieste QUERY. Lo sviluppatore open source Daniele Teti prevede un percorso già osservato per altri elementi HTTP: prima server e strumenti di sviluppo, poi i framework e, più lentamente, browser e API JavaScript come fetch(). La separazione tra interrogazioni complesse e operazioni mutative è ora formalizzata; la sua utilità dipenderà dall’allineamento dell’intero ecosistema di rete.