Il comitato ingegneristico IETF (Internet Engineering Task Force), responsabile dello sviluppo dei protocolli e dell'architettura della rete Internet, ha conferito al metodo HTTP QUERY lo status di "Standard proposto" e ha pubblicato la specifica associata RFC 10008. Il metodo QUERY, nel modo di inviare dati al server, riproduce il metodo POST, ma si differenzia da quest'ultimo per l'accento non sulla registrazione dei dati e sulla modifica dello stato, ma sulla formulazione di richieste di lettura.
Per le problematiche che affronta, il nuovo metodo è simile al GET e consente di inviare richieste che possono essere ripetute o riavviate senza modificare lo stato del server. Come nel metodo POST, i parametri della richiesta nel QUERY non vengono trasmessi nell'URI, ma nel corpo della richiesta. Questo approccio consente di trasmettere un grande volume di parametri nella richiesta, superando il limite sulla dimensione dei parametri nel metodo GET (8000 byte).
GET /feed?q=foo&limit=10&sort=-published HTTP/1.1
Host: example.org
QUERY /feed HTTP/1.1
Host: example.org
Content-Type: application/x-www-form-urlencoded
q=foo&limit=10&sort=-published
I parametri inviati tramite il metodo QUERY non vengono registrati nei log server, che da un lato complica l'analisi delle richieste e la diagnosi dei problemi, ma dall'altro consente di nascondere dati riservati dai log dei server proxy.
Tra le aree di applicazione del metodo QUERY si cita l'invio di richieste a Web API, che restituiscono risultati in formato JSON o XML, o backend che generano contenuti. Per determinare la possibilità di utilizzare il nuovo metodo per le chiamate a server si propone di utilizzare il metodo OPTIONS, e per determinare i formati supportati, il metodo HEAD:
> OPTIONS /contacts HTTP/1.1
> Host: example.org
HTTP/1.1 200 OK
Allow: GET, QUERY, OPTIONS, HEAD
Nel metodo QUERY è prevista la supporto per la memorizzazione nella cache: i server proxy o i gestori possono memorizzare il risultato dell'esecuzione della richiesta, assegnargli un URI per eventuali richieste future tramite il metodo GET e restituire informazioni riguardanti la versione memorizzata nella cache attraverso l'intestazione "Last-Modified". Per verificare la presenza di modifiche dalla richiesta precedente, può essere usata l'intestazione "If-Modified-Since". Per specificare opzioni alternative per l'esecuzione della richiesta nella risposta possono essere forniti i campi "Content-Location" e "Location", dove la differenza è che il primo fornisce un link per ottenere il risultato di una richiesta precedente, mentre il secondo è destinato a ripetere la richiesta con gli stessi parametri.
> QUERY /contacts HTTP/1.1
> Host: example.org
> Content-Type: application/x-www-form-urlencoded
> Accept: application/json
> select=surname,givenname,email&limit=10&match=%22email=*@example.*%22
HTTP/1.1 200 OK
Content-Type: application/json
Content-Location: /contacts/stored-results/17
Location: /contacts/stored-queries/42
Last-Modified: Sat, 25 Aug 2012 23:34:45 GMT
Date: Sun, 17 Nov 2024, 16:10:24 GMT
> GET /contacts/stored-results/17 HTTP/1.1
> Host: example.org
> Accept: application/json
Oltre al tipo «application/x-www-form-urlencoded», per trasmettere parametri nelle richieste QUERY possono essere utilizzati anche formati estesi come JSONPath (application/jsonpath), XSLT (application/xslt+xml) e SQL (application/sql). I formati supportati vengono restituiti server nell'intestazione Accept-Query.
> HEAD /contacts HTTP/1.1
> Host: example.org
HTTP/1.1 200 OK
Content-Type: application/xhtml
Accept-Query: application/x-www-form-urlencoded, application/jsonpath, application/sql
> QUERY /errata.json HTTP/1.1
> Host: example.org
> Content-Type: application/jsonpath
> Accept: application/json
>
> $..[
> ?@.errata_status_code=="Rejected"
> && @.submit_date>"2024"
> ]
> ["doc-id"]
Fonte: opennet.ru
