Per oltre trent’anni il protocollo HTTP ha offerto un insieme di metodi ormai consolidati: GET, POST, PUT, PATCH, DELETE, HEAD, OPTIONS e TRACE. Nel tempo, tuttavia, è emersa una lacuna piuttosto evidente: come eseguire interrogazioni complesse, mantenendo le proprietà di sicurezza e idempotenza tipiche di GET, ma senza essere vincolati ai limiti dell’URL?

Con la standardizzazione del nuovo metodo QUERY, questa esigenza trova finalmente una risposta ufficiale.

Non si tratta semplicemente dell’introduzione di un nuovo verbo HTTP, ma del riconoscimento di un pattern che negli ultimi anni è stato implementato da numerose API mediante soluzioni alternative, spesso basate su POST e con alcune inevitabili rinunce dal punto di vista semantico.

In questo articolo analizzeremo perché è nato il metodo QUERY, quali problemi risolve, quali vantaggi introduce e come può essere utilizzato nella progettazione di API moderne.

---

Perché nasce QUERY

Storicamente GET è il metodo corretto per recuperare informazioni da una risorsa.

Le sue caratteristiche sono ben note:

• è safe, ovvero non modifica lo stato del server;
• è idempotente;
• può essere cacheabile;
• è perfettamente supportato da proxy, CDN e browser.

Il problema emerge quando la richiesta diventa particolarmente articolata.

Pensiamo a scenari come:

• motori di ricerca avanzati;
• interrogazioni multidimensionali;
• filtri dinamici;
• query geospaziali;
• motori di analytics;
• linguaggi di interrogazione strutturati.

In questi casi il client finisce spesso per costruire URL molto lunghi:

GET /search?status=active&type=customer&country=IT&...

oppure

GET /search?filter=(...)

Questa soluzione presenta diversi limiti:

• lunghezza massima dell’URI imposta da browser, proxy o web server;
• encoding complesso di strutture JSON;
• difficoltà di manutenzione;
• problemi di leggibilità;
• esposizione dei parametri nei log.

La conseguenza è stata quasi sempre la stessa: utilizzare POST.

Ad esempio:

POST /search
Content-Type: application/json

{
  "status": "active",
  "country": "IT",
  "roles": [
    "admin",
    "editor"
  ]
}

Dal punto di vista funzionale questa soluzione è perfettamente valida.

Dal punto di vista semantico, invece, introduce una certa ambiguità.

POST nasce infatti per creare risorse o eseguire operazioni che modificano lo stato dell’applicazione. Utilizzarlo esclusivamente per effettuare una ricerca significa perdere informazioni importanti sul significato della richiesta.

È proprio questa lacuna che il metodo QUERY si propone di colmare.

---

Cos’è QUERY

Il metodo QUERY permette al client di inviare un corpo (request body) contenente la descrizione della ricerca, mantenendo però la semantica di una richiesta che non modifica lo stato della risorsa.

In altre parole:

• la richiesta rappresenta un’interrogazione;
• il server restituisce una rappresentazione dei dati;
• non vengono create né modificate risorse.

Un esempio:

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

{
  "country": "IT",
  "status": "active",
  "orders": {
    "min": 10
  }
}

La risposta potrebbe essere:

HTTP/1.1 200 OK

[
  ...
]

Il payload della query diventa finalmente parte del body, senza dover ricorrere a soluzioni non standard.

---

I principali vantaggi

1. Semantica corretta

Il vantaggio più importante è probabilmente quello concettuale.

Quando un server riceve un metodo QUERY, sa immediatamente che:

• il client desidera leggere informazioni;
• non sono previste modifiche allo stato;
• l’operazione rappresenta una ricerca.

Questa chiarezza migliora la progettazione delle API e rende il protocollo più espressivo.

---

2. Query arbitrariamente complesse

Il body può contenere strutture dati molto articolate:

• oggetti JSON;
• array;
• filtri annidati;
• operatori logici;
• criteri di ordinamento;
• paginazione;
• aggregazioni.

Ad esempio:

{
  "filter": {
    "country": "IT",
    "status": [
      "ACTIVE",
      "PENDING"
    ]
  },
  "sort": [
    {
      "field": "lastLogin",
      "direction": "DESC"
    }
  ],
  "limit": 100
}

Una struttura del genere sarebbe estremamente difficile da rappresentare tramite query string.

---

3. URI più puliti

Le API rimangono molto più leggibili.

Invece di:

GET /search?filter=...

si ottiene:

QUERY /search

Il significato della richiesta è contenuto nel body e non nell’URL.

---

4. Migliore evoluzione delle API

Aggiungere nuovi campi nel payload JSON non richiede modifiche alla struttura dell’URI.

Questo rende le API maggiormente estendibili e più semplici da versionare.

---

5. Riduzione dell’esposizione dei parametri

Le query string vengono frequentemente registrate da:

• reverse proxy;
• load balancer;
• web server;
• sistemi di monitoraggio;
• browser history.

Spostare il contenuto della ricerca nel body può ridurre l’esposizione accidentale di parametri sensibili.

È importante però sottolineare che il body non costituisce una misura di sicurezza. Un’infrastruttura può comunque registrarlo, ad esempio tramite sistemi di logging, reverse proxy, WAF o strumenti di osservabilità. La protezione dei dati continua quindi a dipendere dalla configurazione dell’intera catena applicativa.

---

Implicazioni per la sicurezza

Dal punto di vista della cybersecurity il nuovo metodo introduce alcuni aspetti particolarmente interessanti.

Logging più controllato

Molte piattaforme registrano automaticamente gli URL.

Le query molto lunghe finiscono quindi facilmente nei log.

Con QUERY, il payload può essere gestito con politiche differenti, eventualmente applicando masking o sanitizzazione.

---

Minore esposizione nella browser history

Le query string vengono normalmente salvate nella cronologia del browser.

Il body delle richieste, invece, non viene memorizzato nello stesso modo, riducendo la probabilità che filtri complessi o dati sensibili risultino visibili attraverso la cronologia.

---

Supporto da parte delle infrastrutture

Essendo un nuovo metodo HTTP, sarà necessario verificare il supporto lungo tutta la catena:

• API Gateway;
• reverse proxy;
• WAF;
• CDN;
• framework applicativi;
• librerie HTTP;
• strumenti di testing;
• scanner di sicurezza.

Come per ogni estensione del protocollo, l’adozione sarà graduale e richiederà aggiornamenti dell’ecosistema.

---

Quando utilizzare QUERY

Il nuovo metodo è particolarmente indicato quando:

• la richiesta rappresenta esclusivamente una lettura;
• la query è troppo complessa per essere espressa tramite URI;
• è necessario inviare payload JSON articolati;
• si vuole mantenere una semantica HTTP corretta.

Non sostituisce invece:

• GET per interrogazioni semplici;
• POST per la creazione di risorse;
• PUT e PATCH per gli aggiornamenti;
• DELETE per la rimozione.

Ogni metodo continua ad avere uno scopo ben definito.

---

Un esempio concreto

Immaginiamo un sistema SIEM che consenta agli analisti di cercare eventi di sicurezza.

Con GET, una richiesta potrebbe diventare rapidamente ingestibile:

GET /events?...

Con POST, la semantica non sarebbe corretta.

Con QUERY, invece:

QUERY /events

{
  "timerange": {
    "from": "2026-07-01T00:00:00Z",
    "to": "2026-07-07T23:59:59Z"
  },
  "severity": [
    "HIGH",
    "CRITICAL"
  ],
  "source": [
    "firewall",
    "ids"
  ],
  "country": "IT"
}

L’intenzione diventa immediatamente chiara: il client sta eseguendo una ricerca complessa senza alterare lo stato del sistema.

Lo stesso approccio risulta particolarmente efficace anche per piattaforme di threat intelligence, motori OSINT, servizi di analytics, data lake, sistemi di inventory e API Graph-like che necessitano di filtri articolati mantenendo una semantica HTTP rigorosa.

---

Conclusioni

L’introduzione del metodo QUERY rappresenta un’evoluzione naturale del protocollo HTTP.

Più che aggiungere nuove funzionalità, formalizza un’esigenza che sviluppatori e progettisti di API affrontano da anni: eseguire interrogazioni complesse senza dover ricorrere a compromessi semantici.

Per chi progetta API moderne, il beneficio principale è una maggiore coerenza del protocollo. Le operazioni di lettura rimangono chiaramente distinguibili da quelle che modificano lo stato dell’applicazione, mentre il body consente di descrivere query sofisticate in modo naturale, estensibile e facilmente validabile.

Dal punto di vista della sicurezza, QUERY non introduce automaticamente nuove garanzie, ma offre un modello più adatto alla gestione di ricerche avanzate, riducendo alcune criticità tipiche delle query string e permettendo un controllo più granulare sul trattamento dei dati lungo la filiera applicativa.

Come ogni novità nel panorama HTTP, la sua diffusione dipenderà dal supporto offerto da framework, server web, API gateway, strumenti di sicurezza e librerie client. È quindi probabile che nei prossimi anni assisteremo a un’adozione progressiva, simile a quella osservata in passato per altri metodi e meccanismi del protocollo.

L’arrivo di QUERY non rivoluziona HTTP, ma ne completa il modello semantico, offrendo finalmente un metodo progettato per ciò che gli sviluppatori hanno spesso realizzato con POST: effettuare interrogazioni complesse, mantenendo intatta la coerenza architetturale del protocollo.