Il Comitato di ingegneria dell'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 correlata RFC 10008. Il metodo QUERY, per quanto riguarda l'invio di dati al server, è simile al metodo POST, ma si differenzia per il fatto che non è orientato alla registrazione dei dati e alla modifica dello stato, ma alla formulazione di richieste di lettura.
In termini di problemi risolti, il nuovo metodo è vicino a GET e consente di inviare richieste che possono essere ripetute o riavviate senza modificare lo stato sul server. Come nel metodo POST, i parametri della richiesta in QUERY vengono trasmessi non nell'URI, ma nel corpo della richiesta. Questo approccio consente di trasmettere un grande volume di parametri nella richiesta, superando il limite di 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, il che da un lato rende difficile l'analisi delle richieste e la diagnosi dei problemi, ma dall'altro consente di nascondere i dati confidenziali dai log dei server proxy.
Tra i settori di applicazione del metodo QUERY si menziona l'invio di richieste a Web API, che restituiscono risultati in formato JSON o XML, o a backend che generano contenuti. Per determinare la possibilità di utilizzare il nuovo metodo durante le comunicazioni con 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 alla cache: i server proxy o i processori possono salvare il risultato dell'esecuzione della richiesta, assegnargli un URI per un successivo accesso tramite il metodo GET e restituire informazioni sulla fornitura della versione memorizzata nella cache tramite l'intestazione "Last-Modified". Per verificare la presenza di modifiche dalla richiesta precedente, si può utilizzare l'intestazione "If-Modified-Since". Per indicare alternative di esecuzione della richiesta, possono essere specificate le intestazioni "Content-Location" e "Location", le cui differenze consistono nel fatto che la prima trasmette un collegamento per ottenere il risultato di una richiesta precedentemente eseguita, mentre la seconda è destinata a ripetere la richiesta con gli stessi parametri.
> QUERY /contacts HTTP/1.1
> Host: example.org
> Content-Type: application/x-www-form-urlencoded
> Accetta: application/json
> seleziona=cognome, nome, email&limit=10&match="email=*@example.*"
HTTP/1.1 200 OK
Content-Type: application/json
Content-Location: /contacts/stored-results/17
Location: /contacts/stored-queries/42
Last-Modified: Sab, 25 Ago 2012 23:34:45 GMT
Date: Dom, 17 Nov 2024, 16:10:24 GMT
> GET /contacts/stored-results/17 HTTP/1.1
> Host: example.org
> Accetta: application/json
Oltre al tipo «application/x-www-form-urlencoded», i parametri delle QUERY possono utilizzare direttamente 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
> Accetta: application/json
>
> $..[
> ?@.errata_status_code=="Rejected"
> && @.submit_date>"2024"
> ]
> ["doc-id"]
Fonte: opennet.ru
