Por qué generar los tipos
Los modelos tipados detectan errores pronto. Cuando la respuesta de una API está descrita por una interfaz o una clase, tu editor completa los nombres de los campos, el compilador detecta una clave mal escrita y un campo renombrado aparece como error en lugar de un undefined o un null silencioso al ejecutar. Escribir estos tipos a mano para una respuesta con cincuenta campos y tres niveles de anidación lleva tiempo y es fácil equivocarse.
Un generador hace la parte repetitiva en un segundo. El resultado es un buen primer borrador que después revisas, renombras donde haga falta y subes a tu repositorio.
Pruébalo aquí: JSON a código
Abrir la herramienta completaQué deduce un generador de tu ejemplo
Todo sale de los valores de tu JSON. Por eso la calidad del ejemplo importa más que cualquier otra cosa.
| En el JSON | Se deduce como | Ejemplo |
|---|---|---|
| Texto | string | "name": "Ana" |
| Número entero | int, o long por encima de 2.147.483.647 | "id": 42 |
| Número con punto decimal | double o float | "price": 19.0 |
| true o false | boolean | "active": true |
| Texto en formato de fecha ISO | tipo de fecha, si está activado | "created": "2026-10-27T09:30:00Z" |
| null en algunos elementos | tipo anulable | "phone": null |
| Clave que falta en algunos elementos | campo opcional | "discount" solo en un elemento |
| Objeto | un nuevo tipo con nombre | "address": { ... } |
| Lista de objetos | lista de un único tipo combinado | "items": [ { ... }, { ... } ] |
Dale un ejemplo variado
Un generador solo puede describir lo que ve. Si tu ejemplo tiene un pedido con un solo artículo, todos los campos parecen obligatorios y ninguno parece anulable. Si tiene una lista de pedidos en la que unos llevan descuento y otros no, el campo del descuento se marca correctamente como opcional.
Así que, antes de generar, reúne una respuesta con varios elementos, a ser posible con casos límite: un cliente sin teléfono, un pedido sin artículos, un producto con precio decimal. Ponlos en un mismo array en el nivel principal y el generador los combinará todos en un tipo por cada forma.
- Los campos que son null en todos los elementos reciben un tipo general como unknown, object o Any, porque el tipo real no se ve.
- Las listas vacías se convierten en listas de elementos desconocidos por el mismo motivo.
- Un campo que es número en un elemento y texto en otro pasa a ser una unión en TypeScript y un tipo general en los demás lenguajes.
- Los ID grandes por encima de 2^53, como algunas claves de base de datos, son más seguros como texto. JavaScript no puede representarlos exactamente como números.
Nombres, atributos y convenciones
Las claves del JSON suelen seguir el estilo del backend, por ejemplo snake_case si viene de Python o Ruby, mientras que tu código cliente usa otro. Un buen generador renombra los campos según la convención del lenguaje de destino y guarda la clave original en un atributo, así la serialización sigue coincidiendo con los datos.
| Lenguaje | Nombres de campo | Cómo se conserva la clave del JSON |
|---|---|---|
| TypeScript | Sin cambios | No hace falta; las claves raras van entre comillas |
| C# | PascalCase | [JsonPropertyName] o [JsonProperty] |
| Python | snake_case | Field(alias=...) en Pydantic |
| Go | Exportados, con ID y URL | Etiquetas de struct json:"key" |
| Java | camelCase | @JsonProperty (Jackson) |
| Kotlin | camelCase | @SerialName (kotlinx.serialization) |
Los tipos no son validación
Una interfaz de TypeScript desaparece al compilar el código. Si la API envía algo distinto de lo que promete la interfaz, nada lo detiene al ejecutar. Lo mismo pasa con las clases normales en la mayoría de lenguajes: el deserializador rellena lo que puede y deja vacío el resto.
Si los datos vienen de fuera de tu control, valídalos cuando lleguen. En Python, los modelos Pydantic lo hacen sin configuración extra, lo que es un buen motivo para elegir ese estilo en el generador. En TypeScript, a partir de las interfaces generadas puedes escribir esquemas con bibliotecas que comprueban los datos al ejecutar. En C#, Java y Kotlin, marca como obligatorios los campos que deben estar y deja que el serializador falle pronto.
Lista de comprobación antes de hacer commit
- Cambia el nombre del tipo principal de Root a algo con sentido, como Order o Pedido.
- Revisa cada campo tipado como unknown, object, Any o JsonElement y sustitúyelo por el tipo real.
- Revisa los números: ¿un precio es de verdad un double o debería ser un tipo decimal para dinero?
- Revisa las fechas: ¿las quieres como texto o como tipo de fecha con una zona horaria conocida?
- Decide qué campos opcionales lo son de verdad y cuáles solo faltaban por casualidad en el ejemplo.
- Une los tipos que el generador separó solo porque sus ejemplos eran un poco distintos.