Comitetul Ingineresc IETF (Internet Engineering Task Force), responsabil pentru dezvoltarea protocoalelor și arhitecturii rețelei Internet, a acordat metodei HTTP QUERY statutul de „Standard propus” și a publicat specificația asociată RFC 10008. Metoda QUERY, în ceea ce privește modul de trimitere a datelor către server, repetă metoda POST, dar se deosebește de aceasta prin orientarea sa nu pe scrierea datelor și modificarea stării, ci pe formarea de cereri de citire.
În ceea ce privește problemele rezolvate, noua metodă este similară cu GET și permite trimiterea de cereri care pot fi repetate sau repornite fără a modifica starea pe server. La fel ca în metoda POST, parametrii cererii în QUERY sunt transmiși nu în URI, ci în corpul cererii. O astfel de abordare oferă oportunitatea de a transmite un volum mare de parametri în cerere, depășind limita de dimensiune a parametrilor în metoda GET (8000 de octeți).
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
Parametrii transmiși prin metoda QUERY nu sunt reflectați în jurnale servere, ceea ce, pe de o parte, îngreunează analiza cererilor și diagnosticarea problemelor, dar, pe de altă parte, oferă posibilitatea de a ascunde datele confidențiale din jurnalele serverelor proxy.
Printre domeniile de aplicare ale metodei QUERY se menționează trimiterea cererilor către Web API care returnează rezultate în format JSON sau XML, sau backend-uri care generează conținut. Pentru a determina posibilitatea de utilizare a noii metode în contactarea server se propune utilizarea metodei OPTIONS, iar pentru determinarea formatelor acceptate, metoda HEAD:
> OPTIONS /contacts HTTP/1.1
> Host: example.org
HTTP/1.1 200 OK
Allow: GET, QUERY, OPTIONS, HEAD
În metoda QUERY este prevăzută suportul pentru cache — serverele proxy sau procesatorii pot salva rezultatul executării cererii, îi pot atribui un URI pentru accesarea ulterioară prin metoda GET și pot returna informații despre furnizarea versiunii în cache prin antetul „Last-Modified”. Pentru a verifica dacă au existat modificări de la ultima cerere, poate fi utilizat antetul „If-Modified-Since”. Pentru a indica variante alternative de executare a cererii, în răspuns pot fi specificate antetele „Content-Location” și „Location”, care se deosebesc prin faptul că primul transmite un link pentru obținerea rezultatului cererii anterioare, iar al doilea este destinat repetării cererii cu aceleași parametrii.
> 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="email=*@example.*"
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
Pe lângă tipul „application/x-www-form-urlencoded”, pentru transmiterea parametrilor în cereri QUERY pot fi utilizate direct formate extinse, cum ar fi JSONPath (application/jsonpath), XSLT (application/xslt+xml) și SQL (application/sql). Formatele acceptate sunt returnate serverul în antetul 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"]
Sursa: opennet.ro
