Ir para o conteúdo
DevTools / Gerador de código

Gerador de código

Writing model classes by hand from a sample API response is tedious and easy to get subtly wrong — a field that is null in one response becomes a non-optional type, and the mistake surfaces much later as a runtime error. This generator reads a JSON sample and emits typed definitions for TypeScript, Go, Java, Python, Rust, C#, Swift, Kotlin, JSON Schema and SQL, merging array elements so that optionality reflects what the data actually contains rather than what one example happens to show.

Roda inteiramente no navegador — nada é enviado.

JSON sample

Types are inferred from the sample. Fields present in only some array elements become optional.

Generated

Como funciona

The first pass builds a type description from the sample. Each JSON value maps to a primitive — string, number, boolean, null, object or array — and objects and arrays recurse into nested definitions. Arrays are the interesting case: rather than assuming the first element is representative, every element is merged, so an array of objects where one element lacks a field produces an optional field rather than a missing one. A field that is null in any sample becomes nullable, and an array that is empty produces a placeholder type you must fill in yourself.

The output target determines naming. TypeScript interfaces are emitted with optional markers for fields absent from some elements and union types with null for nullable ones. Go structs use exported field names with JSON tags derived from the original keys, and pointer types for genuinely optional values so that the zero value stays distinguishable from absence. Python dataclasses use Optional with a default of None, and Rust structs use Option with serde attributes. In every case the goal is that the generated types describe the sample exactly, so a compile error later means the API changed rather than that the generator guessed.

Edge cases are handled explicitly rather than silently. A key that is not a valid identifier in the target language — containing a hyphen, a space or starting with a digit — is quoted or mapped to a valid name while preserving the wire name in the serialisation metadata, since breaking the mapping would make the code compile and then fail at runtime. Reserved words in the target language get the same treatment. Keys that differ only in case are flagged, because they collide in some languages and not others.

JSON Schema is the one target that describes rather than implements. It produces a draft-07 schema with types, required lists and nested definitions under $defs, which is useful for validating future payloads against the contract you inferred from today's sample. Remember that a single sample only proves what exists, never what is required: a field present in your sample may be optional in the API, and only documentation or a second sample can tell you which.

Casos de uso comuns

  • Generate TypeScript interfaces for an API response before writing the client that consumes it.
  • Create Go structs with correct JSON tags from a webhook payload sample.
  • Produce Python dataclasses for a config file so your editor can autocomplete it.
  • Build a JSON Schema from a sample payload to validate future messages in a test suite.
  • Create SQL DDL for a staging table that matches the shape of an incoming JSON feed.
  • Compare the optionality of fields between two samples to see which are genuinely always present.

Última atualização: 2026-10-14 — o corpo do artigo é exibido em inglês; a interface está traduzida.

Perguntas frequentes

How does it decide which fields are optional?

By merging every object in an array rather than looking at the first one. A field that appears in some elements but not all becomes optional or nullable in the output; a field present in every element becomes required. A single object with no array context cannot tell you anything about optionality, so every field is treated as present. For an accurate result, feed it an array containing several real responses, including the edge cases.

Can it generate code from a JSON Schema?

Not in this direction. The generator reads sample data and infers types, which is the more common need when you are handed a response before you have a specification. If you already have a JSON Schema as the source of truth, use a dedicated schema-to-code generator, since those can carry constraints such as minimum, pattern and enum into the generated types in a way that inference from a single sample cannot.

What happens with fields that are always null in my sample?

They become nullable with no resolvable type, which the generator reports rather than guessing a type for. This is correct behaviour: a field that is null in every sample could be a string, an object or a number, and picking one would produce code that compiles and then fails on the first real value. Get one response where the field is populated and regenerate, or read the API documentation for that field.

Is the generated code production-ready?

It is a correct starting point that compiles and matches your sample, and it is deliberately unopinionated beyond that. It will not add validation, custom serialisation, documentation comments or the naming conventions of your codebase, because those are decisions only you can make. The types and field mappings, which are the tedious and error-prone part, are done for you; the rest is a normal code review away.

Ferramentas relacionadas