OpenAPI en types TypeScript

Convertissez un document OpenAPI ou Swagger en interfaces et types TypeScript.

Entrée

Style de déclarationChamps nullablesDévelopper $ref plutôt que de le nommerGénérer les types de chemin, paramètre et réponseGénérer une union de code de statut par endpointConserver les descriptions comme commentaires de documentationPréfixe de nomIgnorer les endpoints dépréciés

Sortie

OpenAPI en types TypeScript

Collez un document OpenAPI 3 ou Swagger 2 — JSON ou YAML — et cet outil génère des interfaces TypeScript correspondantes pour chaque schéma dans components/schemas, plus un type par endpoint pour ses paramètres de chemin et de requête, corps de requête et réponses. Il économise l'étape d'écrire manuellement les types API chaque fois que la spécification change, et maintient le client synchronisé avec ce que le serveur retourne réellement.

Les options contrôlent la forme de la sortie. Choisissez des déclarations interface ou type, et décidez comment les champs nullables sont représentés : comme une propriété optionnelle (x?: string) ou comme une union avec null (x: string | null). Les références $ref peuvent rester comme des types nommés pointant vers l'interface correspondante, ou être développées en ligne partout où elles sont utilisées. Désactivez « générer les types de chemin, paramètre et réponse » pour obtenir uniquement les schémas de composants, ou activez une union de code de statut pour voir chaque code de réponse qu'un endpoint peut retourner comme un seul type. Les descriptions de la spécification deviennent des commentaires JSDoc au-dessus de chaque champ, et un préfixe de nom évite que les types générés ne collisionnent avec les vôtres lorsque vous les collez dans une base de code plus grande.

L'analyseur lit les constructions OpenAPI standard — schémas d'objet et de tableau, énumérations, oneOf/anyOf/allOf, nullable, additionalProperties — et suit les pointeurs $ref locaux dans le même document. Les endpoints marqués comme dépréciés peuvent être complètement ignorés, et un document qui ne ressemble pas à OpenAPI (pas de section components/schemas ou paths) produit une erreur claire au lieu d'une sortie vide.

Tout s'exécute localement dans votre navigateur — votre spécification API, qui peut décrire un produit non lancé ou un système interne, n'est jamais uploadée nulle part. Copiez les types générés, téléchargez-les en tant que fichier .txt à coller dans un fichier .ts, ou renvoyez la sortie directement à l'entrée pour continuer à l'affiner.

FAQ

Supporte-t-il les documents OpenAPI 3 et Swagger 2 ?

Oui. Les deux utilisent la même structure de chemins, et les définitions Swagger 2 sont lues de la même manière que les components/schemas d'OpenAPI 3.

Que se passe-t-il avec les références $ref qui pointent en dehors du document ?

Seules les références locales (commençant par #/) sont résolues. Une $ref à un fichier externe est conservée comme type nommé mais ne peut pas être développée, car il n'y a rien d'autre à partir duquel la lire.

Puis-je générer des types uniquement pour les endpoints, sans chaque schéma de composant ?

Les schémas de composants sont toujours générés s'ils sont présents, car les types de requête et de réponse les référencent généralement. Désactivez les types de chemin pour ignorer tout ce qui dérive des chemins et conserver uniquement les schémas.

Pourquoi une référence de schéma circulaire reste-t-elle comme type nommé même avec « expand » activé ?

Un schéma qui se référence lui-même, directement ou indirectement via un autre schéma, ne peut pas être inséré en ligne sans boucler indéfiniment, donc cette référence revient au type nommé tandis que les autres se développent toujours.

Mon API est-elle uploadée quelque part ?

Non. L'analyse et la génération de types s'exécutent entièrement dans votre navigateur — votre document ne quitte jamais votre appareil.

OpenAPI en types TypeScript

Outils connexes

OpenAPI en types TypeScript

FAQ