O Comitê de Engenharia da IETF (Internet Engineering Task Force), que se dedica ao desenvolvimento de protocolos e da arquitetura da internet, atribuiu ao método HTTP QUERY o status de "Proposta de Padrão" e publicou a especificação relacionada RFC 10008. O método QUERY, na forma de envio de dados ao servidor, é semelhante ao método POST, mas difere por não se concentrar na gravação de dados e alteração de estado, e sim na formulação de requisições para leitura.
Quanto às tarefas abordadas, o novo método é semelhante ao GET e permite o envio de requisições que podem ser repetidas ou reiniciadas sem alterar o estado no servidor. Assim como no método POST, os parâmetros da requisição no QUERY são transmitidos não na URI, mas no corpo da requisição. Essa abordagem permite a transmissão de um grande volume de parâmetros na requisição, que excede o limite de tamanho de parâmetros no método GET (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
Os parâmetros enviados pelo método QUERY não são registrados nos logs servidores, o que, por um lado, dificulta a análise das requisições e o diagnóstico de problemas, mas, por outro lado, permite ocultar dados confidenciais dos logs de servidores proxy.
Entre as áreas de aplicação do método QUERY, menciona-se o envio de requisições a Web APIs que retornam resultados no formato JSON ou XML, ou backends que geram conteúdo. Para determinar a viabilidade do uso do novo método ao fazer chamadas a servidor recomenda-se utilizar o método OPTIONS e, para determinar os formatos suportados, o método HEAD:
> OPTIONS /contacts HTTP/1.1
> Host: example.org
HTTP/1.1 200 OK
Allow: GET, QUERY, OPTIONS, HEAD
O método QUERY oferece suporte a cache — servidores proxy ou manipuladores podem armazenar o resultado da execução da requisição, atribuir a ele uma URI para futuras chamadas através do método GET e retornar informações sobre a entrega da versão em cache através do cabeçalho "Last-Modified". Para verificar a existência de alterações desde a última requisição, pode ser utilizado o cabeçalho "If-Modified-Since". Para especificar alternativas na execução da requisição, os cabeçalhos "Content-Location" e "Location" podem ser indicados na resposta, sendo que a diferença entre eles é que o primeiro transmite um link para obter o resultado de uma requisição anterior, enquanto o segundo é destinado a repetir a requisição com os mesmos parâmetros.
> QUERY /contacts HTTP/1.1
> Host: example.org
> Content-Type: application/x-www-form-urlencoded
> Aceitar: application/json
> select=surname,givenname,email&limit=10&match="email=*@example.*"
HTTP/1.1 200 OK
Content-Type: application/json
Content-Location: /contatos/resultados-armazenados/17
Localização: /contatos/consultas-armazenadas/42
Última-Modificação: sáb, 25 ago 2012 23:34:45 GMT
Data: dom, 17 nov 2024, 16:10:24 GMT
> GET /contatos/resultados-armazenados/17 HTTP/1.1
> Host: example.org
> Aceitar: application/json
Além do tipo "application/x-www-form-urlencoded", formatos ampliados podem ser usados diretamente para passar parâmetros em consultas QUERY, como JSONPath (application/jsonpath), XSLT (application/xslt+xml) e SQL (application/sql). Os formatos suportados são retornados servidor no cabeçalho Accept-Query.
> HEAD /contatos 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
> Aceitar: application/json
>
> $..[
> ?@.errata_status_code==»Rejeitado»
> && @.submit_date>»2024″
> ]
> ["doc-id"]
Fonte: opennet.ru
