Warum überhaupt Typen erzeugen
Typisierte Modelle fangen Fehler früh ab. Wird die Antwort einer API durch ein Interface oder eine Klasse beschrieben, vervollständigt dein Editor Feldnamen, der Compiler bemerkt einen falsch geschriebenen Schlüssel, und ein umbenanntes Feld taucht als Fehler auf statt als stilles undefined oder null zur Laufzeit. Diese Typen für eine Antwort mit fünfzig Feldern und drei Verschachtelungsebenen von Hand zu schreiben kostet Zeit, und Fehler passieren leicht.
Ein Generator erledigt den eintönigen Teil in einer Sekunde. Das Ergebnis ist ein guter erster Entwurf, den du dann prüfst, wo nötig umbenennst und eincheckst.
Hier ausprobieren: JSON in Code umwandeln
Vollständige Tool-Seite öffnenWas ein Generator aus deinem Beispiel ableitet
Alles stammt aus den Werten in deinem JSON. Deshalb zählt die Qualität des Beispiels mehr als alles andere.
| Im JSON | Abgeleitet als | Beispiel |
|---|---|---|
| Text | string | "name": "Lena" |
| Ganzzahl | int, oder long über 2.147.483.647 | "id": 42 |
| Zahl mit Dezimalpunkt | double oder float | "price": 19.0 |
| true oder false | boolean | "active": true |
| Text im ISO-Datumsformat | Datumstyp, wenn eingeschaltet | "created": "2026-10-27T09:30:00Z" |
| null in manchen Einträgen | nullable Typ | "phone": null |
| Schlüssel fehlt in manchen Einträgen | optionales Feld | "discount" nur in einem Eintrag |
| Objekt | ein neuer benannter Typ | "address": { ... } |
| Liste von Objekten | Liste eines zusammengeführten Typs | "items": [ { ... }, { ... } ] |
Gib ihm ein abwechslungsreiches Beispiel
Ein Generator kann nur beschreiben, was er sieht. Enthält dein Beispiel eine Bestellung mit einem Artikel, wirkt jedes Feld wie ein Pflichtfeld und keines wie nullable. Enthält es eine Liste von Bestellungen, von denen manche einen Rabatt haben und manche nicht, wird das Rabattfeld korrekt als optional markiert.
Sammle also vor dem Erzeugen eine Antwort mit mehreren Einträgen, am besten mit Grenzfällen: ein Kunde ohne Telefonnummer, eine Bestellung ohne Artikel, ein Produkt mit Dezimalpreis. Pack sie auf oberster Ebene in ein Array, dann führt der Generator alle zu einem Typ pro Struktur zusammen.
- Felder, die in jedem Eintrag null sind, bekommen einen allgemeinen Typ wie unknown, object oder Any, weil der echte Typ nicht sichtbar ist.
- Leere Listen werden aus demselben Grund zu Listen mit Einträgen vom Typ unknown.
- Ein Feld, das in einem Eintrag eine Zahl und in einem anderen Text ist, wird in TypeScript zu einer Union und in anderen Sprachen zu einem allgemeinen Typ.
- Große IDs über 2^53, wie manche Datenbankschlüssel, sind als Text sicherer. JavaScript kann sie als Zahlen nicht exakt darstellen.
Namen, Attribute und Konventionen
JSON-Schlüssel folgen oft dem Stil des Backends, zum Beispiel snake_case aus Python oder Ruby, während dein Client-Code einen anderen nutzt. Ein guter Generator benennt Felder nach der Konvention der Zielsprache um und behält den ursprünglichen Schlüssel in einem Attribut, damit die Serialisierung weiterhin zu den Daten passt.
| Sprache | Feldnamen | So bleibt der JSON-Schlüssel erhalten |
|---|---|---|
| TypeScript | Unverändert | Nicht nötig; ungewöhnliche Schlüssel kommen in Anführungszeichen |
| C# | PascalCase | [JsonPropertyName] oder [JsonProperty] |
| Python | snake_case | Field(alias=...) in Pydantic |
| Go | Exportiert, mit ID und URL | Struct-Tags json:"key" |
| Java | camelCase | @JsonProperty (Jackson) |
| Kotlin | camelCase | @SerialName (kotlinx.serialization) |
Typen sind keine Validierung
Ein TypeScript-Interface verschwindet beim Kompilieren. Schickt die API etwas anderes, als das Interface verspricht, hält das zur Laufzeit niemand auf. Dasselbe gilt in den meisten Sprachen für einfache Klassen: Der Deserializer füllt, was er kann, und lässt den Rest leer.
Kommen die Daten von außerhalb deiner Kontrolle, validiere sie beim Eintreffen. In Python erledigen Pydantic-Modelle das von Haus aus, ein guter Grund, im Generator diesen Stil zu wählen. In TypeScript lassen sich aus den erzeugten Interfaces Prüfungen mit Bibliotheken schreiben, die Daten zur Laufzeit kontrollieren. In C#, Java und Kotlin markierst du Felder, die vorhanden sein müssen, als required und lässt den Serializer früh scheitern.
Checkliste vor dem Commit
- Benenne den obersten Typ von Root in etwas Aussagekräftiges um, etwa Order.
- Prüf jedes Feld mit dem Typ unknown, object, Any oder JsonElement und ersetze ihn durch den echten Typ.
- Prüf Zahlen: Ist ein Preis wirklich ein double, oder sollte er für Geld ein Dezimaltyp sein?
- Prüf Datumsangaben: Willst du sie als Text oder als Datumstyp mit bekannter Zeitzone?
- Entscheide, welche optionalen Felder wirklich optional sind und welche im Beispiel nur zufällig fehlten.
- Führ Typen zusammen, die der Generator nur deshalb getrennt hat, weil sich ihre Beispiele leicht unterschieden.