Entradas válidas com significados diferentes
Um documento JSON pode ser objeto, matriz ou valor simples. null é válido mesmo quando o contrato exige um objeto. Alguns números ultrapassam a precisão inteira de JavaScript; nomes repetidos não são interpretados uniformemente pelos analisadores.
| Entrada de demonstração | Leitura sintática | Verificação restante |
|---|---|---|
| {"ok":true} | Válida. | O valor cumpre o contrato? |
| {"ok":true,} | Inválida: vírgula final. | Tratar o erro explicitamente. |
| null | Válida. | O contrato permite null? |
| {"id":9007199254740993} | Número válido, risco de precisão em JavaScript. | Prever uma cadeia para este identificador. |
| {"a":1,"a":2} | Nomes repetidos: interpretação não portável. | Definir e aplicar uma política de rejeição. |
Controlar cada etapa de receção
- Use um analisador mantido, nunca eval. Verifique estado HTTP, tipo de conteúdo, limites de tamanho e tratamento explícito de corpos ausentes ou malformados.
- Valide depois o contrato: tipo raiz, campos obrigatórios, valores permitidos e diferença entre ausência, null e zero. Preserve identificadores longos como cadeias se o contrato o definir.
- Defina limites de profundidade e recursos, política de nomes repetidos e gestão de erros. Não insira cadeias recebidas em HTML ou consultas sem proteção adequada.
Manter erros úteis sem expor dados
Teste respostas parciais, alterações de versão e Unicode. Registe contexto mínimo em vez de segredos ou corpos completos. Uma falha de descodificação não deve tornar-se resultado vazio apresentado como sucesso nem interromper silenciosamente toda a cadeia.
Fontes primárias
Registre erros da API JSON sem vazar payloads.
Um corpo JSON pode conter identificadores, segredos ou dados pessoais. O diagnóstico geralmente precisa do tipo de evento, rota, resultado, identificador de correlação e um detalhe de falha não sensível, em vez do payload completo.
- Classifique os campos e oculte aqueles que não são necessários para o diagnóstico.
- Teste falhas de análise e esquema com valores sintéticos.
- Verificar se os logs de erros e as exportações não copiam payloads completos.
Fonte primária: ACSC and partners — Event logging and threat detection. Método relacionado: consultar o guia prático.
JSON personalizado e chaves de cache
Ponto de revisão adicional: JSON personalizado e chaves de cache. Uma política em nível de representação e testes que buscam vazamento entre contas e conteúdo obsoleto após alterações.
- Escolher retenção: A RFC 9111 distingue diretivas: no-cache requer validação antes da reutilização, no-store proíbe o armazenamento HTTP relevante e private não qualificado exclui o armazenamento compartilhado. Nenhum, por si só, garante a confidencialidade do sistema.
- Inspecionar chaves: Verificar método, URI e dimensões que alteram uma representação. A variável diz respeito aos campos de solicitação; não se trata de autorização. Buscar idioma omitido, negociação de formato e contexto da conta nas camadas de aplicação.
Fonte primária: IETF — RFC 9111, HTTP Caching. Método relacionado: consultar o guia prático.
Separar parsing e fim da leitura
JSON sintaticamente válido pode descrever página incompleta, erro operacional ou continuação. O parser não decide sozinho que a exportação terminou.
- Validar estrutura e metadados de continuação.
- Tratar tokens ausentes segundo contrato.
- Detetar tokens repetidos e páginas sem progresso.
Caso de aceitação reproduzível
Exemplo fictício: estes dados não descrevem clientes nem resultados observados.
Ver dados do caso
{
"page_1_ids": [
"A",
"B"
],
"page_2_ids": [
"B",
"C"
],
"next_cursor": "c2",
"empty_page_has_next_cursor": true
}Decisão esperada
B repete-se. Verifique identidades e siga o cursor mesmo após uma página vazia.
Procedimento de verificação
- Fixe filtros, ordem estável e identidade.
- Teste duplicado e página vazia com cursor.
- Conserve identificadores e condição real de fim.
Fonte primária: Google AIP-158 — Pagination. Método relacionado: consultar o guia prático.