🌐Web ganha novo método de comunicação pela primeira vez em 16 anos
Se você já usou a internet, seu navegador mandou milhões de pedidos usando métodos como GET (pedir uma página) e POST (enviar dados de um formulário). Esses comandos são a base de como a web funciona. Agora, pela primeira vez desde 2009, um novo método foi oficializado: o QUERY. Ele combina o melhor dos dois mundos, permite enviar dados complexos como o POST, mas pode ser armazenado em cache (cópias temporárias que aceleram tudo) como o GET. --- Na prática, isso significa buscas mais rápidas e eficientes em sites e aplicativos, especialmente em APIs, que são os canais por onde sistemas trocam informações entre si. É o tipo de mudança invisível para o usuário final, mas que pode melhorar a velocidade e reduzir custos de infraestrutura para quem constrói na web. Dezesseis anos para aprovar um comando novo dá uma ideia de como os padrões da internet evoluem devagar.
Se você já usou a internet, seu navegador mandou milhões de pedidos usando métodos como GET (pedir uma página) e POST (enviar dados de um formulário). Esses comandos são a base de como a web funciona. Agora, pela primeira vez desde 2009, um novo método foi oficializado: o QUERY. Ele combina o melhor dos dois mundos, permite enviar dados complexos como o POST, mas pode ser armazenado em cache (cópias temporárias que aceleram tudo) como o GET.
— @mehulmpt View on X
O protocolo HTTP ganhou um novo método pela primeira vez desde 2009. O QUERY foi oficializado como alternativa para enviar dados complexos a servidores sem abrir mão do cache nativo de navegadores e redes de distribuição de conteúdo (CDNs). Até aqui, desenvolvedores contavam com o GET para recuperar informações — com restrições de tamanho de URL e exposição de parâmetros na query string — ou com o POST, que permite payloads extensos, mas dificulta o armazenamento temporário de respostas por proxies e edge servers.
O problema que o QUERY resolve
Na arquitetura REST tradicional, o GET é o padrão para consultas. Contudo, requisições com filtros complexos, buscas com dezenas de parâmetros ou estruturas de dados aninhadas ultrapassam os limites práticos de uma URL. O POST resolve essa limitação ao transportar corpos de requisição em JSON ou XML, porém quebra o princípio de idempotência e, por padrão, impede que intermediários armazenem a resposta em cache.
O QUERY ocupa o espaço intermediário. Ele permite enviar um corpo na requisição, como o POST, mas mantém a semântica de operação segura e cacheável, características herdadas do GET. Isso significa que servidores intermediários podem reutilizar respostas anteriores sem recalcular ou reprocessar a lógica no backend, respeitando headers de controle de cache como Cache-Control e ETag.
Implicações práticas para APIs e infraestrutura
Para builders e desenvolvedores brasileiros, a mudança tem efeito direto em custo e performance. APIs que processam buscas pesadas podem reduzir a carga sobre bancos de dados e servidores de aplicação ao permitir que edge nodes respondam requisições idênticas diretamente da borda da rede.
Os ganhos são concretos em cenários como:
- Catálogos de e-commerce com filtros multidimensionais de produto;
- Painéis de análise de dados e fintechs com buscas granulares de transações;
- Sistemas que utilizam GraphQL para consultas de leitura, hoje limitados ao POST e sem cache HTTP nativo.
Com o QUERY, essas consultas complexas passam a ser compatíveis com a infraestrutura de caching existente, sem exigir soluções customizadas em nível de aplicação.
A adoção, no entanto, será gradual. Browsers, proxies, load balancers e frameworks precisam implementar suporte ao novo verbo antes que ele seja amplamente utilizado em produção. Dezesseis anos separam o PATCH, aprovado em 2009, do QUERY. Essa lentidão na evolução dos padrões da web reflete a necessidade de compatibilidade retroativa, mas a formalização abre caminho para modernização de arquiteturas de API no Brasil e no mundo.