Questão de TI - Desenvolvimento de Sistemas — JSON (JavaScript Object Notation) — INSTITUTO AOCP 2024

Integração de dados JSON heterogêneos

Gabarito: letra D. A abordagem mais adequada para lidar com JSONs de múltiplas fontes com estruturas inconsistentes (variações de chaves, tipos de dados, aninhamentos complexos e dados opcionais) é desenvolver uma lógica de normalização que converta todos os JSONs recebidos em um formato padrão, usando mapeamento dinâmico de chaves e tratamento de tipos de dados variáveis. Essa solução é flexível, robusta e eficiente, pois permite absorver as diferenças estruturais sem perder dados e sem exigir que as fontes externas mudem seu formato.

O problema central é a heterogeneidade estrutural dos dados: cada fonte pode usar nomes de chaves diferentes (ex.: nome vs name), tipos distintos (ex.: string vs número para o mesmo campo), campos opcionais que nem sempre aparecem e aninhamentos profundos. Para processar tudo isso de forma confiável, a aplicação precisa de uma camada de normalização — um processo que mapeia as variações para um modelo interno padronizado, aplicando conversões de tipo e tratando a ausência de campos opcionais com valores padrão ou nulos.

A normalização funciona em etapas: primeiro, o JSON é parseado (convertido de texto para uma estrutura de dados da linguagem, como dicionário/objeto); depois, um mapeamento dinâmico identifica as chaves equivalentes entre as fontes (ex.: "nome" e "name" apontam para o mesmo campo interno nome); em seguida, os tipos são convertidos (ex.: se uma fonte envia "idade": "30" e outra "idade": 30, a normalização converte ambas para inteiro); por fim, os campos opcionais ausentes recebem um valor padrão (ex.: null ou um default definido). Esse processo garante que a aplicação trabalhe com um formato único, independente das variações externas.

Um exemplo concreto: suponha que a fonte A envie {"nome": "João", "idade": "30"} e a fonte B envie {"name": "Maria", "age": 25, "email": "[email protected]"}. A normalização mapearia nome/name → nome, idade/age → idade (convertendo string para número), e email seria null para a fonte A (campo opcional ausente). O resultado interno seria sempre {"nome": "...", "idade": 30, "email": ...}.

A distinção importante é entre normalização e validação por schema. A normalização é mais flexível: ela aceita variações e as converte. A validação por schema (alternativa E) é mais rígida: ela exige que os dados estejam em conformidade com um esquema pré-definido, rejeitando ou transformando dados que não se encaixam. No cenário descrito, em que as fontes são inconsistentes e não controladas, a normalização é preferível porque não descarta dados válidos apenas por diferenças estruturais. A validação por schema poderia ser usada como uma etapa complementar, mas não como a abordagem principal.

A pegadinha da banca está em confundir flexibilidade com rigidez. Alternativas como A (rejeitar JSONs fora do padrão) e C (desconsiderar inconsistências) parecem resolver o problema, mas na prática perdem dados ou quebram a integração. A alternativa E (schema) é tentadora porque é uma prática comum, mas não é a mais adequada quando as fontes são heterogêneas e não seguem um padrão único. A alternativa B (tratar como string e manipular texto) é frágil e ineficiente, pois JSON é uma estrutura de dados, não texto livre.

Guarde o critério decisivo: a abordagem deve ser flexível o suficiente para absorver variações sem perder dados, e robusta o suficiente para tratar tipos e campos opcionais. É exatamente isso que a normalização com mapeamento dinâmico entrega — e é nesse ponto que as alternativas se dividem.

Alternativa A — ❌ Incorreta

Rejeitar automaticamente qualquer JSON que não siga o formato esperado é o oposto da flexibilidade necessária. Essa abordagem descartaria dados válidos de fontes que usam nomes de chaves ou tipos diferentes, inviabilizando a integração. O problema não é o formato, mas a variação — e rejeitar não resolve a variação, apenas a ignora.

Alternativa B — ❌ Incorreta

Tratar JSONs como strings e usar manipulação de texto (regex, busca e substituição) é extremamente frágil e ineficiente. JSON é uma estrutura de dados hierárquica; manipulá-lo como texto quebra aninhamentos, escapa caracteres e não lida bem com tipos. Além disso, é um retrabalho enorme para algo que bibliotecas de parsing já fazem de forma nativa.

Alternativa C — ❌ Incorreta

Uma biblioteca de JSON rígida que "desconsidera as inconsistências estruturais e processa somente os campos presentes" é contraditória: se ela é rígida, não lida bem com variações; se processa só os campos presentes, pode perder dados importantes que estão em outras chaves. A abordagem correta é mapear as variações, não ignorá-las.

Alternativa D — ✅ Correta ⟵ GABARITO

A normalização com mapeamento dinâmico de chaves e tratamento de tipos variáveis é exatamente o que o cenário pede. Ela converte todos os JSONs para um formato padrão interno, absorvendo as diferenças de nomenclatura, convertendo tipos e tratando campos opcionais. Isso garante flexibilidade (aceita qualquer variação), robustez (não quebra com dados ausentes ou tipos diferentes) e eficiência (processa uma vez, de forma estruturada).

Alternativa E — ❌ Incorreta

A validação por schema (JSON Schema) é uma prática válida, mas não é a mais adequada quando as fontes são heterogêneas e não controladas. Um schema pré-formatado exigiria que todas as fontes seguissem o mesmo padrão, o que não é o caso. A validação por schema poderia ser usada como etapa complementar após a normalização, mas como abordagem principal ela rejeitaria dados que não se encaixam, repetindo o problema da alternativa A.

Gabarito: letra D