Wenn Unternehmen heute Schnittstellen bereitstellen oder Bestandssoftware modernisieren, führt an HTTP-basierten APIs kaum ein Weg vorbei. Wer einen REST-Server mit Delphi entwickeln möchte, bewegt sich dabei in einem Spannungsfeld aus stabiler Architektur, sicherer Authentifizierung, nachvollziehbarem Betrieb und der Erwartung, dass sich die Lösung über Jahre sauber warten lässt. Delphi ist dafür in vielen Organisationen eine pragmatische Wahl: Es bietet reife Werkzeuge, schnelle Iteration, gute Performance und mit passenden Frameworks einen klaren Weg zu produktionsreifen Services – on-premises, in der Private Cloud oder als Teil hybrider Landschaften.
Dieser Beitrag ordnet ein, welche Delphi-Optionen für REST-Services sinnvoll sind, wie ein sauberes API-Design aussieht und welche Punkte in der Praxis häufig unterschätzt werden: Versionierung, Fehlerbehandlung, Datenbankzugriff, Nebenläufigkeit, Security-Details, Observability und das Deployment als Windows- oder Windows- und Linux-Services. Ziel ist kein „Hello World“, sondern ein belastbarer Leitfaden für B2B-Anforderungen, bei denen Integrationen zu ERP, DMS, CRM oder Portalen zuverlässig funktionieren müssen.
Wann sich ein REST-Server in Delphi besonders lohnt
Delphi-REST-Backends sind häufig dann sinnvoll, wenn bereits Fachlogik in Delphi existiert oder wenn ein Service nah an bestehende Windows- oder Linux-Prozesse angebunden werden muss. Typische Motive in Unternehmensumgebungen:
- Bestandssoftware „API-fähig“ machen: Eine VCL-Anwendung oder ein gewachsener Client-Server-Kern erhält eine REST-Schicht, ohne dass die gesamte Logik neu implementiert wird.
- Integration: Drittsysteme brauchen eine klare, dokumentierte Schnittstelle (z. B. Statusmeldungen, Stammdaten, Dokument-Links, Workflows).
- Entkopplung: Mehrere Clients (Desktop, Web-Portal, Mobile, Batch) sollen dieselben Funktionen nutzen.
- Betriebssicherheit: REST-Services lassen sich gut in Reverse-Proxies, zentrale Authentifizierung und Monitoring integrieren.
- Modernisierung in Etappen: REST-API als Stabilisierungsschicht, während Datenbank, UI oder Module schrittweise erneuert werden.
Wichtig ist eine realistische Abgrenzung: REST ist ein Integrations- und Architekturbaustein. Er ersetzt nicht automatisch ein durchdachtes Domänenmodell, saubere Datenverantwortung oder konsistente Transaktionsgrenzen – genau dort entscheidet sich langfristig die Wartbarkeit.
Framework- und Technologieoptionen in Delphi
Delphi bietet mehrere Wege zum REST-Server. In B2B-Projekten ist weniger die „beste“ Technologie entscheidend als die Passung zu Betrieb, Team-Skills und Lebensdauer der Lösung.
WebBroker: klassisch, robust, nah am HTTP
WebBroker ist ein etabliertes Delphi-Framework für HTTP-Anwendungen. Es ist besonders geeignet, wenn Sie Kontrolle über Request/Response wünschen, eigene Middleware-Logik bauen wollen oder eine schlanke, gut nachvollziehbare Serverkomponente benötigen. WebBroker funktioniert mit verschiedenen HTTP-Stacks und lässt sich in der Praxis gut hinter einem Reverse Proxy (z. B. Nginx, Apache, IIS als Reverse Proxy) betreiben.
Stärken: geringer Overhead, gute Transparenz, gut für „Handwerk“ bei HTTP-Details. Herausforderung: Sie müssen bestimmte Komfortthemen (z. B. Routing, Middleware-Ketten, OpenAPI-Generierung) meist selbst strukturieren oder über Bibliotheken ergänzen.
Delphi Horse: leichtgewichtiges Routing und Middleware
Horse ist ein populäres, schlankes Framework, das Routing und Middleware-Mechanismen ähnlich wie in anderen Ökosystemen bereitstellt. Für Teams, die REST-Services zügig strukturieren wollen, ist Horse oft ein guter Kompromiss: klarer Aufbau, gute Lesbarkeit, gut geeignet für typische API-Endpunkte. Für B2B zählt hier vor allem, dass Sie Ihren Standard sauber festlegen: Fehlerformat, Logging, Auth-Handling, Request-Limits, Timeouts und Tests.
RAD Server: Plattformansatz mit integrierten Bausteinen
RAD Server (ehemals EMS) bietet viele Features „out of the box“, unter anderem Nutzerverwaltung, Push-Funktionalität, Analytics-Bausteine und ein Ökosystem für mobile/mehrere Clients. Das ist dann interessant, wenn Sie tatsächlich eine Plattformlogik nutzen wollen und die Betriebs- und Lizenzanforderungen zu Ihrem Einsatz passen. Für reine Integrations-APIs ist RAD Server nicht zwingend nötig; für einheitliche Client-Backends kann es allerdings ein Beschleuniger sein.
DataSnap: vorhanden, aber strategisch genau prüfen
DataSnap ist in Delphi lange bekannt und kann HTTP/REST-artige Endpunkte bereitstellen. In Modernisierungsvorhaben sollte man DataSnap jedoch strategisch prüfen: Passt es zum geplanten API-Stil, zu Authentifizierungsanforderungen, zu OpenAPI-Dokumentation und zu modernen Betriebsanforderungen? Häufig lohnt es sich, bestehende DataSnap-Logik schrittweise hinter eine neue REST-Schicht zu legen, statt weiter in das alte Modell zu investieren.
Architektur: vom Request bis zur Datenbank ohne Spaghetti
Ein REST-Service wird schnell unübersichtlich, wenn Controller/Handler direkt SQL bauen, Business-Regeln mischen und Seiteneffekte unkontrolliert entstehen. Für langfristige Wartbarkeit ist eine klare Schichtung zentral. In vielen Delphi-Teams hat sich eine Layer-3-Architektur (Transport, Domäne, Persistenz/Integration) als praktikabel erwiesen.
Transport-Schicht: HTTP, Routing, Serialisierung
Diese Schicht nimmt Requests entgegen, validiert grundlegende Parameter, sorgt für Authentifizierung/Autorisierung und liefert strukturierte Antworten. Wichtig: Hier sollten keine komplexen Geschäftsregeln stehen. Stattdessen: Übergabe an Domänenservices, Mapping von DTOs, Fehlerbehandlung.
Domäne: fachliche Regeln, Transaktionen, Konsistenz
Die Domänenschicht kapselt Use-Cases (z. B. „Auftrag anlegen“, „Status ändern“, „Dokument verknüpfen“). Gerade in prozessnaher Unternehmenssoftware ist das die Schicht, die später am meisten lebt. Sie sollte unabhängig vom konkreten HTTP-Framework bleiben, damit Sie sie auch in Batch-Jobs, Windows-Services oder CLI-Tools nutzen können.
Persistenz und Integration: FireDAC, SQL und externe Systeme
Für Datenbanken ist BDE-Ablosung mit nativer Anbindung in Delphi häufig die erste Wahl. Entscheidend ist weniger „BDE-Ablosung mit nativer Anbindung benutzen“, sondern wie: verbindliche Patterns für Connection-Handling, Transaktionsgrenzen, Query-Parameter, Timeouts und Fehlerübersetzung. Auch Integrationen (ERP-Adapter, SMTP, Filesystem, Message Broker, SAML/OIDC-Provider) gehören sauber gekapselt.
API-Design: Ressourcen, Methoden und verlässliche Verträge
Ein REST-Service ist vor allem ein Vertrag. In B2B-Integrationen zahlen sich klare Regeln aus, weil mehrere Teams und Systeme davon abhängen.
Ressourcenorientierung und konsistente Pfade
Statt „/doSomething“ sind Ressourcenpfade meist stabiler: „/customers“, „/orders/123“, „/orders/123/positions“. Nicht jede Operation passt perfekt in CRUD; für Prozessschritte sind Sub-Ressourcen oder Aktions-Endpunkte vertretbar, wenn Sie sie klar begründen und dokumentieren (z. B. „/orders/123/cancel“).
HTTP-Statuscodes und Fehlerformat
Ein häufiger Wartungskiller ist uneinheitliche Fehlerbehandlung. Legen Sie ein Standardformat fest, das Maschinen verarbeiten können, etwa:
- HTTP-Statuscode (400, 401, 403, 404, 409, 422, 500)
- Fehlercode (stabil, dokumentiert)
- Message (für Logs/Operatoren, nicht als alleinige Semantik)
- Correlation-ID (für Support und Tracing)
Für Validierungsfehler ist ein 422 mit Feldliste oft hilfreicher als „400 irgendwas“. Für Konflikte (z. B. Optimistic Locking) ist 409 etabliert.
Versionierung ohne Integrationsbruch
Versionierung ist weniger ein Technikthema als ein Prozess. Bewährt sind:
- URL-Versionierung (z. B. /api/v1/…): sehr klar, aber Pfade ändern sich.
- Header-Versionierung: sauber, aber in manchen Toolchains schwieriger.
- Kompatible Erweiterung: neue Felder ergänzen, alte nicht brechen, Deprecation-Plan definieren.
In B2B ist die kompatible Erweiterung oft der wichtigste Grundsatz: Neue Felder hinzufügen ist meist ok, Felder entfernen oder Semantik ändern erfordert eine neue Version und klare Migrationsfenster.
Sicherheit: Authentifizierung, Autorisierung und Angriffsflächen
Security entscheidet, ob ein REST-Server produktionsfähig ist. Häufige Probleme entstehen nicht durch „fehlende TLS“, sondern durch Details: Token-Lebensdauer, fehlerhafte Rollenprüfung, ungeschützte Admin-Endpunkte, zu breite CORS-Policy oder Log-Ausgaben mit sensiblen Daten.
Transport-Sicherheit: TLS und Reverse Proxy
In vielen Setups terminiert TLS am Reverse Proxy (Nginx, Apache, IIS). Der Delphi-Service läuft intern auf HTTP und ist nur aus dem internen Netz erreichbar. Wichtig: eindeutige Regeln für „X-Forwarded-For“, „X-Forwarded-Proto“ und eine konsequente Behandlung der echten Client-IP (für Rate Limiting, Audit, Geo-Regeln).
JWT, API-Keys oder SSO: was passt wann?
Für Maschinen-zu-Maschinen-Szenarien sind API-Keys oder Client-Credentials-Flows verbreitet. Für Benutzerzugriff in Unternehmenskontexten sind JWTs in Verbindung mit einem Identity Provider (OIDC) häufig praktikabel. In SSO-Landschaften kann SAML 2.0 relevant sein, meist auf Portal-/Gateway-Ebene, die dann Tokens an Ihre API weiterreicht.
Unabhängig vom Mechanismus sollten Sie definieren:
- Token-Prüfung und Key-Rotation
- Scopes/Rollen und deren Abbildung auf Endpunkte
- Mandantenfähigkeit (Tenant-ID im Token vs. Zuordnung in DB)
- Audit-Logging (wer hat was wann getan?)
CORS, Rate Limiting, Input-Validation
Wenn Browser-Clients (z. B. ein Kundenportal) zugreifen, wird CORS relevant. Legen Sie Origins exakt fest, erlauben Sie nur nötige Methoden/Headers und prüfen Sie, ob Credentials genutzt werden. Rate Limiting schützt gegen Missbrauch und unbeabsichtigte Lastspitzen; oft wird es am Reverse Proxy umgesetzt, ergänzt um serverseitige Limits (maximale Body-Größe, Timeouts, Parallelitätsgrenzen).
Input-Validation sollte früh passieren und auf mehreren Ebenen: syntaktisch (JSON-Format, Datentypen), fachlich (Wertebereiche, Statusübergänge) und sicherheitsrelevant (Pfad-/Dateinamen, SQL-Parameter, Header). Parameter müssen immer gebunden werden; dynamisches SQL sollte die Ausnahme sein und klar geprüft werden.
Datenbankzugriff mit FireDAC: Transaktionen, Pooling, Timeouts
In REST-Backends ist der Datenbankzugriff oft die dominierende Laufzeit. Mit FireDAC lassen sich PostgreSQL, SQL Server, MariaDB/MySQL und andere Systeme anbinden. Für B2B-Betrieb sind folgende Punkte entscheidend:
Connection-Strategie und Parallelität
Ein häufiger Fehler ist ein globales Connection-Objekt, das in parallelen Requests geteilt wird. Stattdessen sollten Sie pro Request (oder pro Worker) sauber instanziieren oder über ein kontrolliertes Pooling arbeiten. Die konkrete Umsetzung hängt vom Servermodell ab, aber die Leitlinie bleibt: Thread-Safety bewusst planen, Zustände isolieren, keine impliziten globalen Seiteneffekte.
Transaktionsgrenzen als Teil des Use-Cases
Transaktionen sollten in der Domänenschicht gesteuert werden: Ein Use-Case entscheidet, ob mehrere Operationen atomar sind. Typisch ist „ein Request = eine Transaktion“, aber nicht immer: Manche Endpunkte sind read-only und brauchen keine explizite Transaktion, andere müssen mehrere Tabellen konsistent ändern. Bei Integrationen mit externen Systemen sind Kompensationsstrategien wichtig, weil verteilte Transaktionen selten praktikabel sind.
Timeouts und Backpressure
Setzen Sie Timeouts auf DB- und HTTP-Ebene. Ohne Timeouts stauen sich Requests, Threads und Verbindungen, was bei Lastspitzen den gesamten Service blockiert. Zusätzlich hilft Backpressure: Begrenzen Sie Parallelität oder die Queue-Länge, damit das System kontrolliert „nein“ sagen kann (z. B. 503), statt langsam zu sterben.
Serialisierung, DTOs und Kompatibilität über Zeit
JSON ist Standard, aber die Details zählen: Datumsformate, Null-Werte, Dezimaltrennzeichen, Feldnamen-Konventionen und Encoding. Definieren Sie einen Standard (z. B. ISO-8601 für Datum/Zeit in UTC) und halten Sie ihn konsequent ein.
DTOs statt direktes Exponieren von Datenbankstrukturen
Wenn Ihre API direkt Datenbanktabellen spiegelt, wird jede Datenbankänderung zum API-Bruch. Besser sind DTOs, die auf den Use-Case zugeschnitten sind. Das erlaubt auch, interne Felder (z. B. technische IDs, Flags, Audit-Spalten) nicht zu veröffentlichen und später zu refactoren.
Idempotenz und Wiederholbarkeit
In Unternehmensnetzwerken treten Timeouts und Retries auf. Legen Sie fest, welche Operationen idempotent sind (z. B. PUT) und wie Sie doppelte Requests vermeiden (Idempotency-Key für bestimmte POSTs). Das reduziert Fehlerbilder im Betrieb erheblich.
Dokumentation und Tests: OpenAPI als gemeinsame Sprache
API-Dokumentation ist nicht nur „nice to have“. Sie ist die Grundlage für Integration, Vertragsklarheit und automatisierte Tests. OpenAPI (Swagger) ist hier der De-facto-Standard. Auch wenn Ihr Delphi-Stack OpenAPI nicht automatisch generiert, lohnt sich eine gepflegte Spezifikation, weil sie:
- Client-Generierung ermöglicht (z. B. für C#-Portale oder andere Consumer)
- Regressionen sichtbar macht (Diff von Spezifikationen)
- Testwerkzeuge und Mocking erleichtert
Testpyramide pragmatisch umsetzen
Für Delphi-REST-Services sind meist drei Testebenen sinnvoll:
- Unit-Tests für Domänenlogik (ohne HTTP, ohne DB)
- Integrationstests für Persistenz/Transaktionen (Testdatenbank, Migrationen)
- API-Tests gegen laufenden Service (Statuscodes, Auth, Contract)
Wichtig ist, dass Tests reproduzierbar sind: feste Seed-Daten, klare Cleanup-Strategien und keine Abhängigkeit von Entwickler-Umgebungen.
Betrieb: Windows-Service, Linux-Daemon, Container und Reverse Proxy
Ein REST-Server ist dann „fertig“, wenn er stabil betrieben werden kann. Genau hier entstehen in Projekten die meisten Überraschungen: Log-Rotation, Updates, Zertifikate, Portfreigaben, Benutzerrechte, Startreihenfolgen, Monitoring.
Deployment-Modelle im Vergleich
- Windows- und Linux-Services: passt gut in Windows-zentrierte Infrastrukturen, lässt sich mit bestehendem Monitoring und Rechteverwaltung koppeln.
- Windows- und Linux-Services (systemd): sinnvoll für schlanke Server, Reverse Proxy davor, klare Log- und Restart-Policy.
- Container: bietet reproduzierbare Deployments und erleichtert Rollouts, setzt aber saubere State-Trennung voraus (DB extern, Files in Volumes, Secrets-Handling).
In allen Fällen ist ein Reverse Proxy oft der Schlüsselbaustein: TLS, Kompression, Request-Limits, Header-Policies, optionale Auth-Vorprüfung, Routing zu mehreren Services und saubere Fehlerseiten nach außen.
Konfiguration: 12-Factor-Prinzipien in Delphi-Realität
Auch ohne dogmatisch zu sein, helfen ein paar Regeln: Konfiguration nicht kompilieren, sondern über Environment/Config-Dateien steuern; Secrets nicht ins Repo; unterschiedliche Profiles für Dev/Test/Prod. Achten Sie darauf, dass Log-Level, DB-String, Token-Keys, CORS-Origins und Timeouts zentral und nachvollziehbar sind.
Observability: Logging, Metriken, Tracing
Wenn eine Integration stockt, braucht der Betrieb Antworten: Was ist passiert, wo hängt es, seit wann, wie oft? Ein REST-Service ohne Observability ist teuer im Support.
Strukturiertes Logging und Correlation-IDs
Loggen Sie strukturiert (z. B. JSON oder key/value), nicht nur Text. Jede Anfrage sollte eine Correlation-ID haben, die in Response-Headern zurückkommt und in allen Logzeilen erscheint. Sensible Daten gehören nicht ins Log (Passwörter, Tokens, personenbezogene Inhalte). Stattdessen: Hashes, gekürzte IDs, oder gezielte Debug-Traces in geschützten Umgebungen.
Metriken für Kapazität und Stabilität
Typische Metriken: Request-Rate, Latenzen (p95/p99), Fehlerraten nach Endpoint, DB-Query-Zeiten, Thread-/Worker-Auslastung, Queue-Längen, Anzahl offener Connections. Diese Metriken sind die Grundlage für Kapazitätsplanung und für das Erkennen schleichender Probleme (z. B. Index fehlt, neue Version erzeugt N+1-Queries).
Modernisierung: REST-API als Brücke in die Zukunft
In Delphi-Landschaften ist der REST-Server oft Teil einer Modernisierung, nicht der Endpunkt. Ein typisches Vorgehen in Etappen:
- Fachlogik identifizieren, die als Service sinnvoll ist (Stammdaten, Workflows, Status-Änderungen).
- API-Schicht einführen mit klarer Auth, Fehlerformat, Logging, OpenAPI.
- Datenzugriff konsolidieren (z. B. FireDAC-Standard, Transaktionskonzept, Query-Policies).
- Clients entkoppeln: Desktop, Portale, Services greifen über die API zu.
- Schrittweise Ablösung alter Module, ohne Integrationsbruch für Consumer.
Das lässt sich gut mit weiteren Maßnahmen kombinieren, etwa einer BDE-Ablösung, einem Datenbank-Umbau oder der Einführung zusätzlicher Services für Windows und Linux. Wichtig ist, dass Sie die Schnittstellen als langfristige Verträge behandeln: konservative Änderungen, saubere Deprecation, und Tests gegen die Spezifikation.
Typische Stolpersteine in B2B-Projekten und wie man sie vermeidet
Einige Muster tauchen in der Praxis immer wieder auf:
- Unklare Zuständigkeiten: „Die API macht auch noch X“ führt zu Mischlogik. Besser: Domänenservices mit klaren Use-Cases.
- Fehlende Grenzen: Kein Limit für Body-Größe, keine Timeouts, keine Parallelitätssteuerung.
- Zu frühe Optimierung am falschen Ort: Erst Messpunkte schaffen (Metriken), dann gezielt optimieren (DB, Indizes, Serialisierung).
- Undokumentierte Sonderfälle: 200er Antworten mit Fehlertexten sind schwer integrierbar. Besser: konsistente Statuscodes und Fehlerobjekte.
- Security als Nachtrag: Auth, Rollen, Mandantenfähigkeit und Audit gehören in die Grundstruktur, nicht in einzelne Endpunkte „hineingeflickt“.
Fazit: REST-Server mit Delphi entwickeln – erfolgreich mit klaren Standards
Einen REST-Server mit Delphi zu entwickeln ist in Unternehmen dann besonders wirksam, wenn Sie von Beginn an auf Standards setzen: klare Schichtung, konsistentes API-Design, dokumentierte Verträge (OpenAPI), saubere Authentifizierung und ein Betriebskonzept mit Logging, Metriken und Update-Strategie. Delphi liefert dafür mehrere belastbare Optionen – vom schlanken WebBroker/Horse-Ansatz bis zu plattformorientierten Lösungen wie RAD Server. Entscheidend ist, dass Architektur und Betrieb zusammen gedacht werden: Dann wird aus einer Schnittstelle ein langfristig wartbarer Integrationsbaustein für Portale, Services und Modernisierungspfade.
Wenn Sie Ihren REST-Server in eine bestehende Delphi-Landschaft integrieren oder eine belastbare API als Basis für Portale und Services aufbauen möchten, besprechen wir gern die technischen Rahmenbedingungen:
Im fachlichen Umfeld spielen auch Delphi REST-API und REST-Server und Delphi REST-API eine wichtige Rolle, wenn Integrationen, Datenfluesse und Weiterentwicklung sauber zusammenspielen muessen.
Projekt oder Modernisierungsvorhaben mit Net-Base besprechen.