The Internet Engineering Task Force (IETF), which develops Internet protocols and architecture, has designated the HTTP QUERY method as a "Proposed Standard" and published the associated specification, RFC 10008. The QUERY method replicates the POST method in its method of sending data to the server, but differs in that it focuses on generating read requests rather than writing data and changing state.
The new method is similar to GET in its intended purpose and allows for sending requests that can be repeated or restarted without changing server state. As with the POST method, query parameters in QUERY are passed in the request body rather than the URI. This approach allows for the transmission of a large number of parameters in a request, exceeding the GET method's parameter size limit (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 are not reflected in server logs, which, on the one hand, complicates the analysis of requests and diagnostics of problems, but on the other hand, makes it possible to hide confidential data from proxy server logs.
Among the uses of the QUERY method are sending requests to Web APIs that return results in JSON or XML format, or to content-generating backends. To determine whether the new method can be used when accessing the server, it is recommended to use the OPTIONS method, and to determine supported formats, the HEAD method:
> OPTIONS /contacts HTTP/1.1
> Host: example.org
HTTP / 1.1 200 OK
Allow: GET, QUERY, OPTIONS, HEAD
The QUERY method supports caching: proxy servers or handlers can store the query result, assign it a URI for subsequent access via the GET method, and return information about the cached version via the "Last-Modified" header. The "If-Modified-Since" header can be used to check for changes since the previous request. To specify alternative query execution options, the "Content-Location" and "Location" headers can be specified in the response. The former provides a reference to the result of a previously executed query, while the latter is intended to repeat the query 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=%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
In addition to the "application/x-www-form-urlencoded" type, extended formats such as JSONPath (application/jsonpath), XSLT (application/xslt+xml), and SQL (application/sql) can also be used directly to pass parameters in QUERY requests. Supported formats are returned by the 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
