No tráfego de API moderno, os dados reais de decisão vivem no corpo — não nos headers.
O gerenciamento tradicional de tráfego de Camada 7 geralmente decide com base em URL, método, headers e endereço de origem. Esse modelo frequentemente é suficiente para aplicações web clássicas, mas em arquiteturas de API modernas a distinção crítica geralmente está em campos dentro do corpo da requisição. Identidade de tenant, papel de usuário, tipo de transação, nome do serviço ou metadados de upload de arquivo não estão nos headers — estão em payloads JSON, XML, de formulário ou multipart.
Sem essa visibilidade, os operadores são empurrados para opções ruins. Ou um gateway de API adicional é colocado à frente do gerenciamento de tráfego — adicionando um novo salto, nova licença e novo ônus operacional — ou a própria aplicação é alterada para elevar o valor de decisão para os headers. Para backends legados e críticos para o negócio, essa mudança frequentemente não é viável.
Limitar a inspeção de corpo apenas à segurança também não resolve o problema. Se o WAAP consegue ler o conteúdo, mas o mecanismo de roteamento não consegue usar o mesmo valor, a política de segurança e a política de tráfego acabam em dois mundos separados. O resultado é lógica duplicada, regras inconsistentes e maior chance de erro.
O modelo correto é tornar as capacidades do parser de corpo uma parte nativa da linguagem de regras. JSONPath, XPath, parâmetros de formulário, claims JWT, regex e verificações de mapa/lista devem viver na mesma árvore de expressões, e uma única expressão deve conduzir tanto uma ação de tráfego quanto uma pontuação WAAP.
As Regras Conscientes de Conteúdo do TR7 fecham essa lacuna: campos dentro do corpo deixam de ser apenas dados inspecionados e se tornam sinais que conduzem diretamente a decisão.
Nossa abordagem
O TR7 não trata a consciência de conteúdo como um complemento separado. É uma parte nativa da linguagem de regras de tráfego e segurança.
Funções de parser de corpo são integradas diretamente à linguagem de expressões FX
JSONQUERY, XMLQUERY, XMLPATHEXISTS, PARAM, JWTHEADER e JWTPAYLOAD são funções de primeira classe na linguagem de regras. Os operadores transformam conteúdo do corpo em condições sem escrever código personalizado e vinculam essas condições diretamente a ações de tráfego ou segurança.
Parsers JSON, XML e multipart rodam dentro do runtime
Payloads JSON, XML e multipart são analisados em runtime e expostos ao mecanismo de regras como valores legíveis. Os operadores decidem com base em campos significativos em vez de executar regex bruto sobre cada byte da requisição.
A mesma DSL conduz o gerenciamento de tráfego e a pontuação WAAP
No TR7, uma expressão escrita contra um campo de corpo pode conduzir roteamento, manipulação de headers e pontuação de assinatura WAAP igualmente. Esse modelo compartilhado reduz a lógica duplicada entre regras de tráfego e regras de segurança.
Os modos ADC e WAAP seguem regras de integridade diferentes
No modo ADC, o corpo pode ser lido e, em cenários adequados, reescrito no lado da resposta. No modo WAAP, o corpo nunca é modificado — é lido, pontuado e bloqueado quando o limite de política é excedido.
Capacidades
As Regras Conscientes de Conteúdo transformam dados de payload estruturado em condições legíveis e ações executáveis.
Consultas JSONPath escrevem regras diretamente contra campos de corpo de API
A função JSONQUERY avalia campos de corpo JSON usando semântica JSONPath padrão. Os operadores podem usar valores como `$.user.role`, `$.items[0].sku` ou `$.tenant_id` como condições e vinculá-los ao roteamento de vService, manipulação de headers ou pontuação WAAP. O tráfego de API não é mais direcionado apenas pelo endpoint — é direcionado pelo significado de negócio real da requisição.
Verificações XPath em XML tornam o tráfego SOAP e de serviços empresariais transparente
XMLQUERY, XMLPATHTYPE e XMLPATHEXISTS executam consultas XPath contra corpos XML. O nome do serviço, o nó de ação ou o campo de operação dentro de um envelope SOAP podem conduzir decisões de roteamento e segurança. Isso é particularmente valioso para aplicar despacho e política no nível de serviço sem modificar backends legados. Payloads XML se tornam dados estruturados dentro do mecanismo de regras, reduzindo a dependência de regex frágil.
O tipo de mensagem FIX e o tópico MQTT como condições de regra
Uma regra não tem de parar no HTTP. O tipo e a tag da mensagem FIX, o tópico MQTT e a estrutura do pacote estão disponíveis como condições no mesmo construtor de regras, por isso uma mensagem de ordem malformada ou um tópico inesperado é apanhado na camada de entrega — antes de chegar ao motor de casamento de ordens ou ao broker. O tráfego de trading e IoT costuma ser movido como TCP opaco na esperança de que corra bem; aqui é lido, e a regra que o lê é igual às que a sua equipa já escreve.
Campos de formulário e multipart vinculam decisões de tenant, arquivo e transação
A função PARAM transforma query strings, corpos codificados em formulário e campos de formulário em condições de regras. O parser multipart expõe metadados de upload de arquivo — nome do campo, tipo de conteúdo e tamanho — à política. Esse padrão é útil para portais SaaS, fluxos de upload de documentos e lógica de transação específica de usuário. O tráfego pode ser roteado ou bloqueado com base no contexto de negócio que o formulário carrega.
Os valores de header e payload JWT são consultados com uma única função
JWTHEADER e JWTPAYLOAD expõem os campos de header e payload do token como valores consultáveis por JSONPath. Papel de usuário, tenant, nível de autorização ou claims personalizados se tornam entradas para decisões de tráfego e segurança. Um claim obrigatório pode ser aplicado na borda, claims ausentes podem reprovar a requisição, e o tráfego baseado em papel pode ser direcionado para grupos de backend dedicados — tudo sem incorporar lógica de acesso no código da aplicação.
Lookups de mapa e lista escalam regras em grandes conjuntos de dados
MAP_STR, MAP_REG, MAP_SUB, MAP_IP, MAP_BEG e MAP_END fornecem lookups rápidos contra grandes conjuntos de valores. LIST_STR, LIST_REG, LIST_SUB, LIST_IP, LIST_BEG e LIST_END oferecem o mesmo modelo para verificações baseadas em listas. Listas de tenants, nomes de serviços permitidos, intervalos de IP e grupos de padrões podem ser gerenciados centralmente em vez de como condições únicas, mantendo grandes conjuntos de regras gerenciáveis.
Limites de tamanho de corpo, profundidade e contagem de campos controlam a análise antes de começar
BODY_SIZE, JSON_DEPTH, XML_DEPTH, JSON_KEY_COUNT e XML_NODE_COUNT definem limites de proteção antes de o parser atuar. Payloads superdimensionados, profundamente aninhados ou inflados são rejeitados antes de chegarem ao backend. JSON_DEPTH tem padrão 32 e é ajustável no nível de política. O mesmo controle governa tanto o consumo de recursos quanto o abuso no nível do parser.
Allowed e Must Args constroem um modelo de segurança positivo
JSON_MUST_ARGS, JSON_ALLOWED_ARGS, FORM_MUST_ARGS e FORM_ALLOWED_ARGS verificam se campos esperados estão presentes e se campos inesperados estão ausentes. Em vez de apenas buscar padrões ruins, o modelo declara a forma de uma requisição aceitável. Campos obrigatórios ausentes ou parâmetros inesperados podem ser rejeitados por política. Essa abordagem orientada a contrato é especialmente valiosa em endpoints transacionais críticos.
A reescrita do corpo de resposta permite mascaramento e transformação no modo ADC
No modo ADC, a ação modifyResponse aplica substituição baseada em regex a corpos de resposta. É usada para mascarar dados pessoais, reescrever links ou adaptar endereços internos para consumidores externos. O modo WAAP nunca modifica o corpo — apenas lê e pontua. Essa separação equilibra flexibilidade de tráfego com integridade de segurança na mesma plataforma.
Profundidade operacional
A consciência de conteúdo não é apenas sintaxe de regras — também abrange gerenciamento de buffer, cache de análise, visibilidade de auditoria e comportamento em casos extremos.
Gerenciamento de buffer de corpo
O conteúdo do corpo é armazenado em buffer antes da análise, e o parser JSON, XML ou multipart relevante então processa esse buffer. O buffer de corpo padrão é de 16 KB; parâmetros do sistema podem ser aumentados para payloads JSON ou XML maiores. Quando o limite é excedido, a requisição é rejeitada com 413 para que o backend não seja sobrecarregado com payloads superdimensionados.
Cache de resultado de análise
Os resultados de JSONPath e XPath lidos dentro da mesma requisição são armazenados em cache no espaço de variáveis com escopo de transação. Uma vez que uma regra lê um campo do corpo, as regras subsequentes não reexecutam o parser para o mesmo campo. Isso reduz a latência e o custo de processamento em longas cadeias de regras.
Modelo de integridade WAAP
No modo WAAP, o corpo é lido mas nunca modificado. O conteúdo alimenta assinaturas, pontuação e lógica de limite; uma vez que o limite é excedido, a requisição é bloqueada. A camada de segurança pode agir sobre sinais conscientes de conteúdo enquanto preserva a integridade da requisição de ponta a ponta.
Comportamento de requisição em chunks
A análise de requisições POST em chunks começa após a remontagem dos chunks ser concluída, para que os campos do corpo sejam avaliados como um payload completo e coerente. O tráfego em chunks pode incorrer em uma pequena latência adicional, mas o backend fica protegido de streams de payload parciais e não controlados.
Visibilidade GraphQL
O GraphQL é atualmente tratado via JSONPath: campos como nome de operação e lista de campos dentro do corpo podem ser usados em condições de regras. Isso permite decisões práticas na borda, como separar mutations de queries. A validação profunda de schema está fora do escopo desta capacidade.
Trilha de auditoria e SIEM
Qual regra leu qual campo do corpo é registrado no log de auditoria. As equipes de operações podem rastrear por que uma requisição específica foi roteada, rejeitada ou pontuada em seu SIEM. Essa rastreabilidade evita que as regras conscientes de conteúdo se comportem como uma caixa preta.
Quando usar
Rotear pelo valor de tenant dentro do JSON
Equipes SaaS podem despachar tráfego para pools de backend separados com base no campo tenant_id dentro do corpo JSON. A separação de tenants acontece sem alterar o código da aplicação, e a política de tráfego é gerenciada na borda.
Despachar serviços empresariais por ação SOAP
Em sistemas bancários e governamentais, o nó de ação dentro de um envelope XML pode conduzir o despacho para diferentes grupos de serviço. O contrato de serviço legado permanece intacto enquanto as decisões de tráfego se tornam conscientes de conteúdo.
Separar tráfego GraphQL por tipo de operação
Equipes de engenharia podem direcionar queries e mutations para origens separadas com base no campo operationName. Operações com leitura intensa e escrita intensa chegam a grupos de backend dedicados.
Aplicar decisões de acesso em claims JWT
Para aplicações críticas, claims de papel e tenant dentro do payload JWT podem ser aplicados na borda. Requisições com claims obrigatórios ausentes nunca chegam ao backend; requisições com claims válidos são colocadas sob a política de tráfego apropriada.
Perguntas frequentes
Quais tipos de conteúdo os parsers de corpo suportam?
A mesma regra pode conduzir tanto o tráfego ADC quanto a política WAAP?
Qual é a diferença de integridade entre o modo ADC e o modo WAAP?
Como os conteúdos JWT são usados em expressões de regras?
Como o sistema lida com corpos muito grandes ou profundamente aninhados?
Se múltiplas regras leem o mesmo campo do corpo, a análise é executada mais de uma vez?
Tome decisões de API sobre o corpo — não sobre o header
Roteamento e segurança conscientes de conteúdo em campos JSON, XML, multipart e JWT. Vamos percorrer uma configuração ao vivo nos seus próprios serviços.