Komitet inżynieryjny IETF (Internet Engineering Task Force), zajmujący się rozwojem protokołów i architektury internetu, nadał metodzie HTTP QUERY status „Proponowany standard” i opublikował związaną z tym specyfikację RFC 10008. Metoda QUERY pod względem sposobu wysyłania danych do serwera powtarza metodę POST, ale różni się od niej orientacją nie na zapisywanie danych i zmianę stanu, a na formułowanie zapytań o odczyt.
Pod względem rozwiązywanych zadań nowa metoda jest zbliżona do GET i pozwala na wysyłanie zapytań, które mogą być powtarzane lub wznawiane bez zmiany stanu na serwerze. Tak jak w metodzie POST, parametry zapytania w QUERY są przekazywane nie w URI, a w ciele zapytania. Takie podejście pozwala na przesyłanie dużej ilości parametrów w zapytaniu, przekraczających limit rozmiaru parametrów w metodzie GET (8000 bajtów).
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
Parametry wysłane metodą QUERY nie są odzwierciedlane w logach serwerów, co z jednej strony utrudnia analizę zapytań i diagnozowanie problemów, ale z drugiej strony umożliwia ukrycie poufnych danych z logów serwerów proxy.
Wśród obszarów zastosowania metody QUERY wymienia się wysyłanie zapytań do Web API, które zwracają wyniki w formacie JSON lub XML, lub backendów generujących treść. Aby określić możliwość użycia nowej metody przy dostępie do serwera zaleca się użycie metody OPTIONS, a dla określenia obsługiwanych formatów metody HEAD:
> OPTIONS /contacts HTTP/1.1
> Host: example.org
HTTP/1.1 200 OK
Allow: GET, QUERY, OPTIONS, HEAD
W metodzie QUERY przewidziano wsparcie dla cachowania — serwery proxy lub przetwarzacze mogą zapisać wynik wykonania zapytania, przypisać mu URI do późniejszego dostępu przez metodę GET i zwrócić informacje o wydaniu wersji z cache'u przez nagłówek „Last-Modified”. Aby sprawdzić obecność zmian od ostatniego zapytania, może być stosowany nagłówek „If-Modified-Since”. W celu wskazania alternatywnych wariantów wykonania zapytania w odpowiedzi mogą być podawane nagłówki „Content-Location” oraz „Location”, których różnica polega na tym, że pierwszy przekazuje link do uzyskania wyniku wcześniej wykonanego zapytania, a drugi ma na celu powtórzenie zapytania z tymi samymi parametrami.
> QUERY /contacts HTTP/1.1
> Host: example.org
> Content-Type: application/x-www-form-urlencoded
> Akceptuj: 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
> Akceptuj: application/json
Oprócz typu «application/x-www-form-urlencoded» do przesyłania parametrów w zapytaniach QUERY można również używać rozszerzonych formatów, takich jak JSONPath (application/jsonpath), XSLT (application/xslt+xml) i SQL (application/sql). Obsługiwane formaty są zwracane serwerem w nagłówku 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
> Akceptuj: application/json
>
> $..[
> ?@.errata_status_code==»Odrzucony»
> && @.submit_date>»2024″
> ]
> [«doc-id»]
Źródło: opennet.ru
