Por que gerar tipos
Modelos tipados pegam erros cedo. Quando a resposta de uma API é descrita por uma interface ou uma classe, o editor completa os nomes dos campos, o compilador percebe uma chave escrita errada e um campo renomeado aparece como erro, em vez de um undefined ou null silencioso em tempo de execução. Escrever esses tipos à mão para uma resposta com cinquenta campos e três níveis de aninhamento leva tempo e é fácil de errar.
Um gerador faz a parte repetitiva em um segundo. O resultado é um bom primeiro rascunho, que você depois revisa, renomeia onde precisar e faz o commit.
Experimente aqui: JSON para código
Abrir a página completa da ferramentaO que um gerador deduz do seu exemplo
Tudo vem dos valores do seu JSON. Por isso a qualidade do exemplo importa mais que qualquer outra coisa.
| No JSON | Deduzido como | Exemplo |
|---|---|---|
| Texto | string | "nome": "Ana" |
| Número inteiro | int, ou long acima de 2.147.483.647 | "id": 42 |
| Número com ponto decimal | double ou float | "preco": 19.0 |
| true ou false | boolean | "ativo": true |
| Texto no formato de data ISO | tipo de data, se ativado | "criado": "2026-10-27T09:30:00Z" |
| null em alguns itens | tipo anulável | "telefone": null |
| Chave ausente em alguns itens | campo opcional | "desconto" só em um item |
| Objeto | um novo tipo com nome | "endereco": { ... } |
| Lista de objetos | lista de um tipo combinado | "itens": [ { ... }, { ... } ] |
Use um exemplo com variedade
Um gerador só consegue descrever o que vê. Se o seu exemplo tem um pedido com um item, todos os campos parecem obrigatórios e nenhum parece anulável. Se tem uma lista de pedidos em que alguns têm desconto e outros não, o campo de desconto é marcado corretamente como opcional.
Então, antes de gerar, junte uma resposta com vários itens, de preferência incluindo casos extremos: um cliente sem telefone, um pedido sem itens, um produto com preço decimal. Coloque todos numa lista no nível principal e o gerador combina todos eles num tipo para cada formato.
- Campos que são null em todos os itens recebem um tipo genérico como unknown, object ou Any, porque o tipo real não aparece.
- Listas vazias viram listas de itens desconhecidos pelo mesmo motivo.
- Um campo que é número num item e texto em outro vira uma union no TypeScript e um tipo genérico nas outras linguagens.
- IDs grandes acima de 2^53, como algumas chaves de banco de dados, ficam mais seguros como texto. O JavaScript não consegue representá-los exatamente como números.
Nomes, atributos e convenções
As chaves do JSON costumam seguir o estilo do backend, por exemplo snake_case vindo de Python ou Ruby, enquanto o código do cliente usa outro. Um bom gerador renomeia os campos para a convenção da linguagem de destino e guarda a chave original num atributo, para que a serialização continue batendo com os dados.
| Linguagem | Nomes dos campos | Como a chave do JSON é mantida |
|---|---|---|
| TypeScript | Sem mudança | Não precisa; chaves incomuns ficam entre aspas |
| C# | PascalCase | [JsonPropertyName] ou [JsonProperty] |
| Python | snake_case | Field(alias=...) no Pydantic |
| Go | Exportados, com ID e URL | struct tags json:"chave" |
| Java | camelCase | @JsonProperty (Jackson) |
| Kotlin | camelCase | @SerialName (kotlinx.serialization) |
Tipos não são validação
Uma interface TypeScript desaparece quando o código é compilado. Se a API mandar algo diferente do que a interface promete, nada impede isso em tempo de execução. O mesmo vale para classes simples na maioria das linguagens: o desserializador preenche o que consegue e deixa o resto vazio.
Se os dados vêm de fora do seu controle, valide quando eles chegam. No Python, os modelos Pydantic fazem isso direto, o que é um bom motivo para escolher esse estilo no gerador. No TypeScript, dá para escrever, a partir das interfaces geradas, validações com bibliotecas que conferem os dados em tempo de execução. Em C#, Java e Kotlin, marque como obrigatórios os campos que precisam estar presentes e deixe o serializador falhar cedo.
Checklist antes do commit
- Renomeie o tipo principal de Root para algo com sentido, como Pedido.
- Revise cada campo tipado como unknown, object, Any ou JsonElement e troque pelo tipo real.
- Confira os números: um preço é mesmo double, ou deveria ser um tipo decimal para dinheiro?
- Confira as datas: você quer como texto, ou como tipo de data com fuso horário conhecido?
- Decida quais campos opcionais são opcionais de verdade e quais só estavam faltando no exemplo.
- Junte tipos que o gerador separou só porque os exemplos eram um pouco diferentes.