O novo método HTTP QUERY

Explicação sobre o método HTTP QUERY, recém-definido pela RFC 10008

Ao lidar com buscas complexas em APIs RESTful existentes, tanto GET quanto POST tinham limitações; para resolver isso, após longas discussões, o método QUERY foi padronizado

Limitações do GET

• Enviar filtros complexos ou consultas relacionais como parâmetros de URL deixa a URL excessivamente longa e pode esbarrar nos limites de caracteres de navegadores ou servidores
• Caracteres não ASCII ou especiais exigem codificação, aumentando o tamanho da requisição
• Não há uma forma padronizada de representar arrays ou estruturas aninhadas (ex.: roles[]=admin vs roles=admin)
• Como servidores/middlewares registram parâmetros de URL em logs, isso pode ser um problema ao transmitir dados sensíveis
• Enviar um corpo de requisição com GET não é explicitamente proibido pela especificação, mas proxies/firewalls/navegadores tratam isso de formas diferentes, tornando-o praticamente inviável na prática

Problemas da alternativa com POST

• É possível enviar um corpo de requisição, mas POST é definido como não idempotente (non-idempotent), portanto uma nova tentativa automática em caso de falha não é segura
• Proxies ou middlewares não conseguem reconhecer que se trata de uma operação somente leitura, impossibilitando otimizações como cache automático
• Semanticamente, usar POST, que é voltado à criação/processamento de recursos, para buscas não está alinhado aos princípios de design RESTful

Método QUERY

• Um novo método HTTP que, como GET, é seguro (safe) e idempotente (idempotent), mas pode incluir um corpo de requisição
• Pode ser armazenado em cache, mas a implementação de cache é mais complexa do que com GET, pois o corpo da requisição deve ser incluído na chave de cache
• Em resumo, seu objetivo central é “substituir o POST em requisições somente leitura”

Observações

• O suporte a QUERY por clientes/proxies/servidores ainda é limitado, e pode levar tempo até haver suporte completo
• Quando parâmetros de consulta simples com GET são suficientes, não há necessidade de mudar
• Se for necessário compartilhar a URL dos dados filtrados ou salvá-la nos favoritos, GET continua sendo adequado

[jongyeol]

Enviar um corpo de requisição em GET não é explicitamente proibido pela especificação, mas como cada proxy/firewall/navegador lida com isso de um jeito diferente, na prática é inviável de usar

Hmm... será que não pensaram que, dependendo de proxy/firewall/navegador, o método QUERY talvez ainda não seja adotado pelos próximos 10 anos? Ou será que fizeram isso pensando bem no longo prazo?

[tesha001]

Acho que deve ser a segunda opção.

[click]

Lembro de ter tido um problema em que a API do serviço de uma certa empresa recebia POST, mas não funcionava se os mesmos parâmetros de URL não fossem passados juntos.
Na Coreia, ainda há bastante gente que olha para PUT ou DELETE e pensa “o que é isso?”, então não faço ideia de quanto tempo vai levar para até o QUERY se estabelecer.

[sea715]

??? : não inventa de fazer REST, só padroniza tudo com POST

[savvykang]

???: POST é bom para segurança

[ultimategamer]

O documento RFC está em https://datatracker.ietf.org/doc/rfc10008/.
O GET tem a desvantagem de deixar a URL mais longa, mas também parece ter a vantagem de permitir compartilhar o próprio endereço da URL, como quando se quer compartilhar o resultado de um filtro de consulta específico do ElasticSearch.

Como provavelmente há muitos lugares em que as requisições GET são usadas implicitamente com a premissa de serem digitadas na barra de endereços do navegador, parece que vai levar bastante tempo para isso se consolidar, mais do que apenas o suporte técnico.