The IETF (Internet Engineering Task Force), responsible for the development of Internet protocols and architecture, has granted the HTTP QUERY method the status of 'Proposed Standard' and published the related specification RFC 10008. The QUERY method, in terms of data transmission to the server, mirrors the POST method, but differs in its focus on reading requests rather than data writing and state changes.
In terms of the tasks it addresses, the new method is close to GET and allows sending requests that can be repeated or restarted without changing the server's state. Similar to the POST method, the parameters in QUERY requests are passed not in the URI, but in the request body. This approach allows for transmitting a larger volume of parameters in the request, exceeding the parameter size limit of the GET method (8000 bytes).
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
Parameters sent via the QUERY method do not appear in the logs servers, which on one hand complicates the analysis of requests and troubleshooting but on the other hand allows for the concealment of sensitive data from proxy server logs.
Among the applications of the QUERY method is the ability to send requests to a Web API that returns results in JSON or XML format or to backends generating content. To determine the feasibility of using the new method when accessing server it is suggested to use the OPTIONS method, and to determine supported formats use the HEAD method:
> OPTIONS /contacts HTTP/1.1
> Host: example.org
HTTP/1.1 200 OK
Allow: GET, QUERY, OPTIONS, HEAD
The QUERY method includes support for caching — proxy servers or handlers can save the result of the request execution, assign it a URI for subsequent access via the GET method and return information about the delivery of the cached version through the 'Last-Modified' header. To check for changes since the last request, the 'If-Modified-Since' header can be used. To indicate alternative execution options in the response, the 'Content-Location' and 'Location' headers may be specified, with the difference that the first provides a link to obtain the result of a previously executed request, while the second is intended for repeating the request with the same parameters.
> 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
In addition to the type "application/x-www-form-urlencoded" for passing parameters in QUERY requests, extended formats such as JSONPath (application/jsonpath), XSLT (application/xslt+xml), and SQL (application/sql) can also be used directly. Supported formats are returned proxy server in the Accept-Query header.
> 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"]
Source: opennet.ru
