Un tour d'horizon neutre, avec sources citées, des options de client OpenAPI et de génération de code disponibles pour les développeurs Delphi et C++ Builder en 2026 : sgcOpenAPI, OpenAPI Generator, Swagger Codegen, mORMot 2, TMS XData avec son compagnon OpenAPI Delphi Generator, et la voie du client REST codé à la main. Chaque affirmation sur une fonctionnalité renvoie à la documentation officielle du projet.
Un résumé d'un paragraphe pour chaque option, avec un lien vers la documentation officielle ou le dépôt. La comparaison détaillée est dans la matrice ci-dessous.
eSeGeCe · Commercial
Suite de composants commerciale Delphi / C++ Builder. Analyse les spécifications OpenAPI 3.x JSON / YAML et Swagger 1.x / 2.x, puis génère des interfaces, records et énumérations Object Pascal natifs qui compilent proprement sous VCL et FireMonkey de Delphi 7 à RAD Studio 13. Fournit plus de 1 195 SDK Pascal préconçus pour Amazon AWS (280+), Google Cloud (250+), Microsoft Azure (650+) et Microsoft Graph (15+). Le code généré n'a aucune dépendance externe au-delà du runtime sgcOpenAPI.
Communauté OpenAPI Tools · Apache 2.0 (open source)
Outil Java open source, à l'origine forké depuis Swagger Codegen, fournissant plus de 60 générateurs client et plus de 40 générateurs de stubs serveur. Génère des clients et/ou des serveurs pour C, C#, C++ (cpp-restsdk, Qt5, Oat++, Tizen, Unreal Engine 4), Go, Java, Kotlin, PHP, Python, Rust, TypeScript et bien d'autres. La liste officielle des générateurs n'inclut pas de cible Delphi / Object Pascal / Free Pascal.
SmartBear / communauté · Apache 2.0 (open source)
Le projet original de générateur de code Java de SmartBear, à partir duquel OpenAPI Generator a été forké en 2018. Prend en charge ActionScript, Ada, Apex, Bash, C#, C++, Clojure, Dart, Elixir, Erlang, Go, Groovy, Haskell, Java, Kotlin, Lua, Node.js, Objective-C, Perl, PHP, PowerShell, Python, R, Ruby, Rust, Scala, Swift et TypeScript. La ligne 3.x prend en charge OpenAPI 3.0 ; la ligne 2.x ne prend en charge qu'OpenAPI 2.0 (Swagger). Il n'y a pas de générateur Delphi ou Object Pascal dans aucune des deux lignes.
Arnaud Bouchez / Synopse · MPL / GPL / LGPL (open source)
mORMot 2 fournit mormot.net.openapi.pas, qui lit un document OpenAPI 3.x ou Swagger 2.0 (fichier ou URL) et émet des unités client FPC / Delphi Pascal — records de haut niveau et tableaux dynamiques comme DTO, énumérations Pascal pour les valeurs d'enum, et traduction des codes de statut HTTP en exceptions. L'unité cible FPC et Delphi 7 / 2009 et ultérieur, et s'exécute dans le cadre du framework mORMot SOA / ORM plus large.
TMS Software / Landgraf Software · Commercial (XData) / Apache 2.0 + Commons Clause (generator)
TMS XData est un framework commercial Delphi de remoting REST / JSON / ORM. Un serveur XData peut publier un document OpenAPI (anciennement Swagger) à /openapi/swagger.json pour ses propres endpoints, et se combine avec SwaggerUI / Redoc. Le compagnon OpenAPI Delphi Generator (à l'origine fourni dans XData, maintenant un projet open source séparé à landgraf-dev/openapi-delphi-generator) consomme des documents Swagger 2.0 / OpenAPI 3.0 et émet des interfaces Delphi et des classes DTO pour utilisation avec TXDataClient.
Indy Project / Embarcadero · BSD / MPL (Indy) · EULA RAD Studio (THTTPClient)
Une réalité courante : les développeurs écrivent le client REST à la main en utilisant TIdHTTP (Indy) ou System.Net.HttpClient.THTTPClient (livré avec Delphi). Pas de génération de code, pas de schéma ; marshalling JSON manuel avec les unités JSON RTL (ou TJSONObject). L'authentification, la logique de nouvelle tentative et la pagination sont également faites à la main.
Un point () signifie que le projet documente un support natif. Un tiret (—) signifie que le projet ne le fournit pas nativement. Un tilde (~) signifie partiel / via un add-on / non explicitement documenté — consulte la section Sources pour ce que nous avons pu vérifier.
| Fonctionnalité | sgcOpenAPI | OpenAPI Generator | Swagger Codegen | mORMot 2 OpenAPI client generator | TMS XData & OpenAPI Delphi Generator | Hand-coded REST clients (Indy / THTTPClient) |
|---|---|---|---|---|---|---|
| Génère un client Delphi Client Object Pascal natif depuis OpenAPI 3.x | — | — | — | |||
| Génère du code C++ Builder Cibles C++ Builder VCL / FMX (BCC32 / BCC64) | ~ | ~ | ~ | ~ | — | |
| Génère des stubs serveur Échafaudage côté serveur depuis une spec OpenAPI | — | — | ||||
| Client HTTP/2 Transport HTTP/2 natif dans le client généré | ~ | ~ | — | ~ | ~ | |
| DTO JSON typés Classes / records / enums fortement typés | ~ | |||||
| Helpers OAuth2 / JWT Flux OAuth2 intégrés et helpers JWT | ~ | |||||
| Helpers async / sync Modèles d'appel à la fois asynchrones et synchrones | ~ | |||||
| Runtime multiplateforme Win / macOS / Linux / iOS / Android | ||||||
| SDK vendor groupés AWS / Azure / GCP / Microsoft Graph préconçus | — | — | — | — | — | |
| Usage commercial autorisé La licence autorise un usage commercial à code source fermé | ||||||
| Maintenance active Release ou activité taguée au cours des 12 à 18 derniers mois | ~ | |||||
| Modèle de licence Type de licence | Commercial | Apache 2.0 (open source) | Apache 2.0 (open source) | MPL / GPL / LGPL | Commercial (XData) + Apache 2.0 + CC (générateur) | BSD / MPL (Indy) · EULA RAD Studio (THTTPClient) |
Chaque option ici a un public réel. Le bon choix dépend de si tu as besoin de stubs serveur en plus des clients, des chaînes d'outils Pascal que tu prends en charge, de tes préférences de licence et de si les SDK vendor groupés te font gagner du temps.
Choisis sgcOpenAPI quand tu veux un seul outil commercial qui génère du code client Delphi 7–13 et C++ Builder depuis n'importe quelle spec OpenAPI 3.x ou Swagger 2.x, quand tu veux des SDK Pascal préconçus pour AWS, Azure, Google Cloud ou Microsoft Graph déjà groupés, quand tu cibles VCL plus FireMonkey pour macOS / Linux / iOS / Android, et quand tu n'as besoin d'aucune dépendance runtime externe au-delà des unités sgcOpenAPI.
Choisis OpenAPI Generator quand ton équipe construit des clients ou des stubs serveur dans des langages autres que Delphi — C#, Java, Go, TypeScript, Rust, Python — depuis la même spec OpenAPI, quand tu as besoin à la fois de clients et de stubs serveur depuis un seul outil, ou quand la licence Apache-2.0 et une grande communauté de contributeurs de templates t'importent.
Choisis Swagger Codegen quand tu utilises déjà l'écosystème SmartBear / Swagger (SwaggerHub, Swagger Editor) de bout en bout, quand tu veux le successeur officiellement maintenu le plus proche du générateur de code historique Swagger 2.0, et quand tes cibles sont les langages JVM / .NET / scripting grand public plutôt que Delphi.
Choisis le générateur OpenAPI mORMot 2 quand ton projet utilise déjà mORMot pour l'ORM, le SOA ou l'hébergement, quand tu veux un générateur de code natif Pascal open source sous MPL / GPL / LGPL, ou quand tu cibles FPC sur Linux / BSD / macOS à la fois pour le générateur client et le code résultant.
Choisis TMS XData quand tu construis aussi le serveur en Delphi et veux serveur + client + remoting ORM d'un seul fournisseur, quand le parcours SwaggerUI / Redoc de tes propres contrats de service est une exigence, ou quand tu utilises déjà TMS Business / All-Access sous licence. Choisis le OpenAPI Delphi Generator autonome quand tu n'as besoin que d'une génération de code côté client et préfères la licence Apache 2.0 + Commons Clause.
Choisis un client REST codé à la main quand la surface d'API est minuscule (une poignée d'endpoints), quand tu ne peux pas livrer de composants tiers pour des raisons de licence ou de conformité, ou quand l'API n'a pas de spec OpenAPI publiée et qu'un générateur ne t'apporterait rien. Indy et THTTPClient sont tous deux livrés avec RAD Studio, donc il n'y a pas de dépendance supplémentaire.
Notes courtes sur les différences si tu passes depuis une des options ci-dessus. Pas d'esprit antagoniste — juste un mappage pratique.
OpenAPI Generator ne cible pas Delphi, donc « migration » ici signifie générer des clients C# / Java / TS en parallèle du client Delphi sgcOpenAPI depuis la même spec. Si ton ancienne configuration était un wrapper C# construit par OpenAPI Generator consommé depuis Delphi via COM ou REST, sgcOpenAPI supprime cette couche en produisant directement le client Delphi.
Swagger Codegen ne cible pas Delphi. Si ton ancien workflow exportait un client C# ou Java générique et l'enveloppait pour Delphi, sgcOpenAPI te permet de générer le client Delphi directement depuis la même spec et supprime la couche wrapper.
Le générateur client OpenAPI de mORMot vit à l'intérieur du framework plus large. Si ton application n'utilise que le générateur et pas les couches SOA / ORM / WebSocket, sgcOpenAPI te donne un ensemble de composants autonomes, prêt à l'emploi, sans les unités supplémentaires. Inversement, si tu utilises aussi les contrats SOA et l'ORM de mORMot, passer uniquement pour le générateur OpenAPI signifie réimplémenter ces parties, ce que sgcOpenAPI ne fournit pas.
Si tu utilises actuellement l'importateur intégré d'XData pour générer des clients depuis des spécifications Swagger tierces, note que l'importateur a été extrait dans le projet open source landgraf-dev/openapi-delphi-generator — les classes dans XData sont documentées comme dépréciées. sgcOpenAPI est un générateur différent, soutenu commercialement, qui lit nativement OpenAPI 3.x, regroupe des SDK pour les principales plateformes cloud, et cible Delphi 7–13 plus C++ Builder.
Les clients codés à la main vieillissent mal quand la surface d'API grandit ou quand le service amont publie de nouveaux endpoints. sgcOpenAPI peut générer les mêmes DTO et signatures de méthodes depuis la spec publiée en quelques secondes, libérant la logique codée à la main pour les parties qui en ont vraiment besoin (nouvelles tentatives personnalisées, télémétrie, glue métier). Le code généré utilise un transport HTTP similaire, donc le modèle mental du développeur reste proche.
Chaque cellule de la matrice ci-dessus renvoie à l'une de ces pages de documentation officielles, dépôts ou notes de version. Toutes les URL ont été vérifiées par HEAD au moment de la rédaction.