Développer un serveur REST avec Delphi : architecture, sécurité et exploitation en pratique

Quiconque souhaite développer un REST-Server avec Delphi poursuit rarement un objectif en soi dans l’entreprise. Il s’agit le plus souvent d’établir des interfaces fiables entre des systèmes existants, des portails, des services et des bases de données — avec des exigences claires en matière d’exploitation, de sécurité et de maintenabilité. L’important n’est pas tant la rapidité de la première réponse d’un endpoint que la stabilité du service au quotidien : des scénarios d’erreur traçables, des accès aux données contrôlés, une authentification propre, des responsabilités architecturales claires et un déploiement adapté aux environnements Windows et Linux.

Delphi est pragmatique pour cela dans de nombreuses organisations : la logique métier existante peut être réutilisée, les performances sont en règle générale suffisantes, et il existe plusieurs manières d’exposer des API HTTP. En pratique, les options se distinguent moins par la question « peut-on faire REST ? » que par la transparence et l’exploitation : dans quelle mesure logging, timeouts, règles de reverse proxy, versioning, documentation OpenAPI et mécanismes de sécurité peuvent-ils être mis en œuvre de façon cohérente ?

Ce billet situe les approches principales Delphi et indique ce à quoi la direction IT, les administrateurs et les responsables techniques de projet doivent prêter attention : du design d’API à la sécurité et à l‘BDE-Ablösung mit nativer Anbindung des accès aux données, jusqu’à l’observability (logs, métriques, tracing) et le déploiement en tant que Windows- ou Windows- et Linux-Services. L’objectif est de fournir une base robuste pour des intégrations vers ERP, DMS, CRM ou portails clients — sans placer les internals d’un framework au centre.

Quand un REST-Server en Delphi est particulièrement pertinent

Un backend Delphi-REST est souvent judicieux lorsque Delphi est déjà en place dans l’entreprise ou lorsque l’on veut réutiliser la logique métier et les accès aux données des applications existantes. Situations B2B typiques :

• Rendre la logiciel existant API‑compatible : une application VCL ou un noyau client‑serveur reçoit une couche REST afin que portails, systèmes externes ou services internes puissent accéder de façon standardisée.
• Intégration et découplage : plusieurs consommateurs (desktop, portail web, traitements batch, partenaires) doivent utiliser les mêmes processus métier sans accès direct à la base de données ni interfaces par fichiers.
• Modernisation par étapes : déployer d’abord une API stable, puis refondre progressivement l’UI, des modules ou la base de données. L’API devient une frontière contrôlée et réduit les effets de bord.
• Exploitation et sécurité : les API HTTP se gèrent bien derrière des reverse proxies, peuvent être centralement authentifiées et intégrées à des stacks de monitoring.

Il est important d’avoir la bonne attente : REST est une surface d’intégration, pas un substitut à la cohérence métier. Démarrer sans modèle de domaine clair, sans frontières transactionnelles définies ou sans responsabilité des données aboutit rapidement à une API accessible mais coûteuse à maintenir et à supporter sur le long terme.

REST-Server en Delphi : options en vue d’ensemble

Delphi propose plusieurs voies pour exposer un service REST. Pour les décideurs, la question n’est pas tant « laquelle est la plus moderne » que : comment s’aligne-t-elle sur la structure de l’équipe, le modèle d’exploitation, la durée de vie attendue et les exigences de conformité ?

Delphi WebBroker : léger, transparent, bien contrôlable

WebBroker est un framework Delphi établi pour les applications HTTP. Il est proche du protocole (request/response), donc facile à suivre, et attrayant pour de nombreux scénarios B2B où la gestion contrôlée des erreurs, le traitement propre des headers et une pile limitée sont importants. WebBroker se place typiquement sans problème derrière un reverse proxy qui termine le TLS et applique des règles de sécurité centralisées.

Conséquence pour la pratique : de nombreuses fonctions de confort (conventions de routing, chaînes de middleware, maintien d’OpenAPI) doivent être ajoutées de manière structurée. Ce n’est pas un inconvénient lorsque les standards d’architecture sont déjà prioritaires.

Delphi Horse : routing et middleware pour des standards d’API clairs

Delphi Horse est léger et mise sur un routing compréhensible combiné au principe du middleware. Middleware signifie ici : des étapes de traitement réutilisables entourant l’endpoint, par exemple authentification, logging, limitation de débit ou validation des requêtes. Pour beaucoup d’équipes, c’est une approche productive car elle permet d’imposer des standards de façon centralisée.

Important pour l’exploitation : définissez tôt un format d’erreur unifié, des timeouts, des tailles maximales de requêtes et une norme de logging. Sans ces règles, le système restera fonctionnel mais deviendra inutilement coûteux en support et en évolutions.

RAD Server : approche plateforme avec composants intégrés

RAD Server (anciennement EMS) adopte plutôt une approche plateforme avec des fonctions intégrées comme la gestion des utilisateurs et d’autres composants. Cela peut convenir lorsque plusieurs clients partagent un backend commun et que les fonctionnalités plateforme sont utilisées délibérément. Pour des API d’intégration pures, ce n’est pas automatiquement le meilleur choix ; la transparence, les faibles dépendances et un modèle d’exploitation léger pèsent souvent davantage.

DataSnap : évaluer réalistement les installations existantes

DataSnap est historiquement présent dans de nombreux environnements Delphi et peut exposer des endpoints de type HTTP/REST. Pour de nouveaux projets, il convient toutefois de vérifier son adéquation au style d’API prévu, à l’authentification (p. ex. JWT), à OpenAPI/Swagger et aux exigences opérationnelles modernes. Une voie pragmatique est souvent : réutiliser la logique existante mais placer une couche REST clairement définie en façade qui impose les standards de sécurité, de logging et de versioning.

Architecture qui tient en exploitation et en maintenance

Une erreur fréquente dans les projets REST est le modèle « le handler fait tout » : les paramètres HTTP sont lus, on compose directement du SQL, on implémente des règles métier et on ajoute du logging en passant. Cela va vite au départ, mais conduit à du code difficile à tester et à des modifications instables.

Dans les environnements d’entreprise, une couchement clair fait ses preuves. Une structure pragmatique courante est une architecture Layer-3 (trois couches) qui sépare les responsabilités :

Couche transport : HTTP, auth, validation, format de réponse

C’est ici que la requête est reçue, une validation de base est effectuée et un format de réponse cohérent est produit. Cette couche comprend aussi l’authentification et l’autorisation (qui peut faire quoi) ainsi que des règles techniques comme les limites de requête, le CORS ou l’attribution de Correlation‑IDs (identifiants uniques par requête pour le traçage).

Couche domaine : cas d’utilisation métier plutôt que logique d’endpoint

La couche domaine encapsule les workflows métier tels que « créer une commande », « changer le statut » ou « lier un document ». L’essentiel : cette logique doit être aussi indépendante que possible du framework HTTP. Ainsi, le même domaine peut être utilisé par un Windows- et Linux-Service, un daemon Linux ou un processus batch sans duplication de logique.

Persistenz und Integration : FireDAC, base de données, ERP/DMS/SMTP

Cette couche centralise l’accès aux bases de données et aux systèmes externes. Pour Delphi, BDE-Ablosung mit nativer Anbindung est le stack d’accès aux données usuel pour connecter proprement PostgreSQL, SQL Server, MariaDB/MySQL ou Firebird. L’important n’est pas seulement « utiliser FireDAC », mais d’imposer des règles contraignantes : gestion des connexions, frontières transactionnelles, timeouts, liaison de paramètres, traduction des erreurs techniques en codes d’erreur API et stratégies de retry unifiées là où elles sont pertinentes métier.

API‑Design : stable sur des années, pas seulement jusqu’au go‑live

Dans les environnements B2B, une API est une interface maintenue durablement. Le mot clé est compatibilité : les consommateurs comptent sur des champs, des codes d’état et une sémantique stables. Plus ces règles sont définies clairement, moins il y a d’effort en intégration, support et releases.

Ressources et chemins : cohérence plutôt que créativité

Les API stables sont typiquement orientées ressources : «/customers», «/orders/123», «/orders/123/items». Les actions de processus peuvent être modélisées comme des sous‑ressources ou des endpoints d’action clairement justifiés, par exemple «/orders/123/cancel» si un modèle CRUD pur ne convient pas métier. L’essentiel est une convention unifiée, documentée et adoptée par l’équipe.

Méthodes HTTP et codes d’état : signaux clairs pour les consommateurs

Une API facile à intégrer respecte la sémantique HTTP attendue : GET pour lecture, POST pour création, PUT/PATCH pour modification, DELETE pour suppression. Tout aussi important : un comportement d’erreur cohérent. Pour l’exploitation, un objet d’erreur standardisé est utile et devrait contenir :

• HTTP‑Status (p. ex. 400, 401, 403, 404, 409, 422, 500)
• code d’erreur stable (lisible par machine, documenté)
• Correlation‑ID (pour l’association rapide dans les logs)
• détails optionnels (p. ex. erreurs de champ lors de la validation)

Un écueil fréquent est de renvoyer des « 200 OK » avec un message d’erreur dans le corps. Cela complique les intégrations et conduit à une logique cliente fragile.

Versioning et extensions compatibles

Le versioning est un problème de processus et de communication, pas seulement une question technique. Les approches usuelles sont le versioning dans l’URL (p. ex. «/api/v1») ou dans les headers. Dans beaucoup d’entreprises, le principe le plus important est : étendre de façon compatible. Ajouter de nouveaux champs est généralement sans conséquence. Supprimer ou changer la signification d’un champ nécessite une nouvelle version et une fenêtre de migration clairement communiquée. Cela réduit les ruptures d’intégration et rend les releases planifiables.

Sécurité : authentification, autorisation, surfaces d’attaque

Un service REST est une porte d’entrée potentielle. Beaucoup de problèmes de sécurité ne viennent pas d’une absence de chiffrement, mais d’erreurs de détail : permissions trop larges, durées de vie de token excessives, endpoints d’administration non protégés, règles CORS non contrôlées ou logs contenant des données sensibles.

TLS et reverse proxy : responsabilités réseau claires

Dans des architectures typiques, le TLS est terminé au niveau du reverse proxy (p. ex. Nginx, Apache ou Microsoft IIS agissant en reverse proxy). Le service Delphi fonctionne en interne sur HTTP et n’est accessible que depuis le réseau interne. Il est important d’avoir des règles propres pour « X‑Forwarded‑For » et « X‑Forwarded‑Proto » afin que l’IP client et le protocole soient correctement interprétés. Ces informations sont pertinentes pour l’audit, le rate limiting et le diagnostic.

JWT, API‑Keys et SSO : ce qui convient en pratique

Pour les intégrations système‑à‑système, les API‑Keys ou des mécanismes Client‑Credentials sont répandus. Pour les accès utilisateurs en contexte entreprise, les JWT (JSON Web Token) combinés à un fournisseur d’identité central (p. ex. OIDC) sont souvent pragmatiques. Dans les environnements SSO, SAML 2.0 peut aussi être pertinent (standard de Single Sign‑On entre portail/gateway et identity provider).

Indépendamment du procédé choisi, il convient de définir :

• rotation des clés et certificats (comment les signatures sont‑elles renouvelées ?)
• rôles/scopes (quelles permissions pour quels endpoints ?)
• multitenancy (comment l’affectation des tenants est‑elle rigoureusement appliquée ?)
• audit‑logging (qui a déclenché quelle action métier et quand ?)

Validation d’entrée, CORS et rate limiting

La validation d’entrée doit s’effectuer en plusieurs couches : syntaxique (types de données, structure JSON), métier (plages de valeurs, transitions d’état) et sécurité (noms de fichiers, chemins, headers). Pour les clients navigateur, le CORS est important (quels origins et headers sont autorisés). CORS doit être configuré de manière restrictive. Le rate limiting protège contre les abus et les pics de charge ; il est souvent appliqué au reverse proxy et complété par des limites côté serveur (taille maximale du body, timeouts, parallélisme limité).

FireDAC et accès aux bases : la stabilité naît des règles

Dans les backends REST, l’accès à la base est souvent le facteur dominant de latence et de stabilité. FireDAC apporte les possibilités techniques, mais la robustesse opérationnelle vient de garde‑fous.

Gestion des connexions et concurrence

Une erreur classique est une connexion à la base partagée globalement et utilisée en parallèle par plusieurs requêtes. Dans un REST-Server traitant des requêtes en parallèle (threads/workers), il faut savoir quels objets sont thread‑safe et lesquels ne le sont pas. Concrètement : gérer proprement les connexions et les objets de requête par requête ou unité de travail, ou utiliser un pooling contrôlé selon le modèle de serveur. Cela réduit les deadlocks, les erreurs sporadiques et les problèmes difficiles à reproduire.

Transactions alignées sur les use‑cases

Les transactions appartiennent au domaine : un cas d’utilisation décide de ce qui doit être atomique. Souvent, « une requête = une transaction » est une règle raisonnable, mais pas systématique. Les endpoints en lecture n’ont souvent pas besoin d’une transaction explicite, tandis que les opérations en écriture doivent modifier plusieurs tables de façon cohérente. Pour les intégrations externes (ERP, DMS, webhooks), les transactions distribuées sont la plupart du temps irréalistes ; on s’appuie alors sur des ordres d’exécution clairs et une logique de compensation (comment nettoyer un succès partiel ?).

Timeouts, backpressure et échec contrôlé

Sans timeouts, les requêtes, threads et connexions DB s’accumulent. Définissez donc des timeouts au niveau HTTP et DB. Le backpressure est complémentaire : limitez le parallélisme et la longueur des files afin que le système sous charge réponde de façon contrôlée avec 503 (Service Unavailable) plutôt que de tomber en panne par épuisement des ressources. Pour l’exploitation, une erreur rapide et claire vaut mieux qu’un blocage pendant plusieurs minutes.

Payloads, DTOs et compatibilité long terme

JSON est la norme, mais l’interopérabilité tient aux détails : format date/heure, fuseau, valeurs nulles, représentation décimale, noms de champs et encodage. Définissez un standard (p. ex. ISO‑8601 en UTC) et appliquez‑le de façon uniforme.

DTOs plutôt que structures de base exposées

Les DTOs (Data Transfer Objects) sont des modèles de données API optimisés pour l’échange. Ils ne devraient pas simplement refléter les tables de la base. Ainsi, les changements internes de schéma ne provoquent pas immédiatement des ruptures d’API. On contrôle également quels champs internes ne doivent pas sortir (par ex. flags, colonnes d’audit) et comment refactorer en interne ultérieurement sans mettre en danger les intégrations.

Considérer idempotence et retries

Dans les réseaux d’entreprise, timeouts et retries sont normaux. Définissez quelles opérations sont idempotentes (exécution multiple donne le même résultat) et comment éviter les POSTs en double, par exemple via un Idempotency‑Key pour certaines opérations d’écriture. Cela réduit les doublons, les états incohérents et les tickets de support.

Documentation et tests : OpenAPI comme socle commun

Une API en B2B est rarement utilisée par une seule équipe. OpenAPI (Swagger) sert de langage commun pratique car les spécifications peuvent être automatisées : génération de clients, mocking, tests de contrat et diff entre versions. Même si la pile Delphi ne génère pas tout automatiquement, une spécification soignée vaut comme artefact central.

Couverture de tests pragmatique qui réduit les coûts d’exploitation

Une structure de tests utile pour des services REST comporte en général trois niveaux :

• Unit‑tests pour la logique domaine (sans HTTP, sans base)
• Tests d’intégration pour l’accès aux données et le comportement transactionnel (avec base de test et jeux de données reproducibles)
• Tests API/contract contre un service en fonctionnement (codes d’état, auth, format d’erreur, versioning)

Pour les administrateurs et les équipes d’exploitation, l’essentiel est que les tests soient reproductibles et ne dépendent pas d’environnements de développeurs. Plus l’environnement de test ressemble au déploiement final, moins il y a de risques de surprises après des mises à jour.

Déploiement et exploitation : Windows-Service, Linux-Service, conteneurs

Un REST-Server est considéré comme « prêt » en production lorsque son exploitation est stable : comportement start/stop, rotation des logs, mises à jour, droits, ouvertures de ports, certificats, monitoring et possibilités de rollback claires.

Windows- et Linux-Services : modèles d’exploitation éprouvés

Sous Windows, l’exploitation en tant que Windows- und Linux-Services est souvent logique, car des mécanismes pour le type de démarrage, la récupération, les droits et le monitoring existent déjà. Sous Linux, on utilise souvent un service systemd (systemd étant le gestionnaire de services standard), qui contrôle les politiques de redémarrage, l’intégration au logging et l’ordre de démarrage. Dans les deux cas, un reverse proxy en amont simplifie TLS, les politiques d’entêtes, le rate limiting et le routage.

Conteneurs : reproductibilité, mais uniquement avec séparation claire de l’état

Les conteneurs peuvent uniformiser les déploiements et accélérer les rollouts. La condition est une séparation nette de l’état : base de données externe, fichiers dans des volumes, secrets via un gestionnaire de secrets. Sans cette discipline, on obtient des états mixtes difficiles à maintenir, visibles lors d’incidents ou de restaurations.

Configuration : traçable, séparée par environnement, sans secrets dans le repo

Un modèle de configuration cohérent aide : paramètres distincts pour Dev/Test/Prod, définition centrale des niveaux de logs, données de connexion DB, timeouts, origins autorisés et clés de tokens. Les données sensibles ne doivent pas être dans le dépôt de code source. Pour les audits et l’exploitation, il est important que les modifications de configuration soient traçables et puissent être déployées de façon contrôlée.

Observability : logs, métriques et tracing comme conditions d’exploitation

Quand les intégrations ralentissent, l’exploitation a besoin de réponses : quels endpoints sont impactés, depuis quand, avec quel taux d’erreur, et quelle dépendance est lente ? Sans observability, chaque incident devient une enquête manuelle.

Logging structuré et Correlation‑IDs

Le logging structuré (Key/Value ou JSON) permet des analyses via des outils et facilite le filtrage par endpoint, tenant, code d’erreur ou Correlation‑ID. Chaque requête devrait recevoir une Correlation‑ID renvoyée aussi dans l’en‑tête de réponse. Les données sensibles comme mots de passe, tokens ou contenus personnels ne doivent pas être loggés ; le masquage, le hashing ou des logs de debug limités à des environnements isolés sont utiles.

Métriques pour capacité et stabilité

Des métriques éprouvées sont le taux de requêtes, les latences (p. ex. p95/p99), les taux d’erreur par endpoint, les temps DB, le nombre d’workers/threads actifs, l’utilisation des connexions et la longueur des files d’attente. Ces indicateurs servent à la planification de capacité et permettent de détecter des problèmes graduels (indices manquants, nouvelles dépendances, plans de requêtes défavorables).

Voie de modernisation : REST comme frontière stable pour des systèmes Delphi évolutifs

Dans de nombreux environnements Delphi, l’API REST n’est pas l’état final mais un composant de stabilité et de modernisation. Une approche éprouvée et à risque mesuré se fait par étapes :

1. Prioriser les use‑cases : quelles fonctions doivent être exposées (métadonnées, changements d’état, accès aux documents, validations) ?
2. Définir les standards API : auth, format d’erreur, versioning, logging, timeouts, rate limits, OpenAPI.
3. Extraire le domaine : structurer la logique métier pour qu’elle ne soit pas liée à l’UI ou à des endpoints particuliers.
4. Consolider l’accès aux données : règles FireDAC, concept transactionnel, baselines de performance, politiques de requêtes.
5. Basculer progressivement les consommateurs : le desktop, les portails et d’autres services utilisent l’API ; les accès directs à la base sont réduits.

Le résultat est un système évolutif par étapes : des modules peuvent être renouvelés sans que des changements se propagent de façon incontrôlée à tous les clients.

Pièges typiques dans les projets B2B REST

Certains scénarios d’erreurs reviennent fréquemment et sont évitables par des règles claires :

• Formats d’erreur non uniformes : le support et l’intégration deviennent inutilement difficiles. Solution : un objet d’erreur standardisé avec codes d’erreur stables.
• Sécurité ajoutée en retard : rôles, multitenancy et audit sont « ajoutés plus tard ». Solution : les planifier comme structure de base, pas improviser endpoint par endpoint.
• Absence de limites : absence de limites de body, de timeouts et de parallélisme provoque des pannes sous charge. Solution : reverse proxy plus backpressure côté serveur.
• Base trop couplée à l’API : chaque changement de schéma casse les consommateurs. Solution : DTOs et use‑cases clairement définis.
• Trop peu d’observabilité : les problèmes ne sont pas mesurables. Solution : Correlation‑IDs, logs structurés, métriques clés.

Conclusion : REST avec Delphi implique la responsabilité de l’interface et de l’exploitation

Développer un REST-Server avec Delphi réussit durablement en entreprise lorsque l’architecture et l’exploitation sont planifiées ensemble dès le départ. Le choix du framework (WebBroker, Horse, RAD Server ou une migration depuis DataSnap) a son importance, mais n’est pas le levier principal. La différence se fait par des standards clairs en matière de design d’API, d’authentification, de gestion des erreurs, de versioning, d’accès aux données FireDAC, de timeouts ainsi que d’observability et de déploiement en tant que Windows- ou Windows- und Linux-Services. Ainsi, une interface devient un composant d’intégration stable qui facilite la modernisation au lieu de la bloquer.

Dans le contexte métier, une Delphi REST-API et une Delphi REST-API und REST-Server jouent un rôle important lorsque intégrations, flux de données et évolution doivent coexister proprement.

Discuter d’un projet ou d’une modernisation avec Net-Base.