REST-serverarkitektur med Delphi til virksomheder

Mange virksomheder står i dag over for en lignende situation: En etableret fagapplikation (ofte Delphi/VCL) afbilder centrale processer, men skal pludselig betjene nye kanaler. En kundeportal kræver data og sagsforløb, mobile brugere forventer sikre adgangsveje, tredjepartssystemer (ERP, DMS, CRM, BI) kræver integrationer. I den situation virker en REST-API som det oplagte skridt. I praksis fejler API-initiativer dog sjældent på HTTP eller JSON – men på uklar ansvarsfordeling mellem klient, server og datalagring.

En bæredygtig REST-Server-arkitektur med Delphi opstår ikke ved blot at lægge „et par endpoints“ over eksisterende databasetabeller. Den opstår, når virksomheden ser faglige regler, sikkerhedskrav, dataejerskab, transaktionsgrænser og driftskoncepter i sammenhæng. REST-Serveren bliver dermed et stabilt kontraktlag mellem faglogik og forbrugere: Desktop-client, portal, services, integrationspartnere. Netop her kommer Delphis styrker til deres ret: hurtig udvikling, robust runtime, performant native kode, god databaseintegration (f.eks. ved BDE-Ablösung med native binding) og muligheden for kontrolleret at kapsle faglogik i biblioteker eller servermoduler.

Denne artikel beskriver, hvordan virksomheder kan planlægge en REST-Server med Delphi sådan, at den forbliver fagligt konsistent, passer ind i eksisterende systemlandskaber og ikke bliver en driftsmæssig fejlskilde. Fokus er på arkitekturprincipper, typiske faldgruber i moderniseringsprojekter og konkrete byggesten for sikkerhed, dataadgang, versionering og observability.

Hvorfor en REST-API i virksomheden er en arkitekturbeslutning

I en klassisk client-server-verden var mange regler implicit fordelt i desktop-klienten: valideringer, statusændringer, beregninger, delvist endda rettigheder. Så længe der kun var én klient, var det ukritisk – fagligt uheldigt, men håndterbart. Når flere forbrugere får adgang til de samme forretningsobjekter, bryder modellen sammen:

• En portal kan ikke „genbruge“ klientens valideringer.
• Mobile apps skal kunne fungere offline, men må ikke duplikere faglige regler.
• Integrationer kræver stabile, versionerede kontrakter og klar fejlesemantik.
• Compliance kræver sporbare adgang, rollemodeller og audit-muligheder.

APIen bliver stedet, hvor faglogik, rettigheder og dataadgang løber sammen. Dens arkitektur afgør derfor, om jeres system forbliver udvidelsesdygtigt på lang sigt – eller om I blot påfører jer ny teknisk gæld.

Delphi som platform for REST-Servere: Styrker og typiske anvendelsesscenarier

Delphi forbindes i virksomheder ofte med desktop-applikationer. Til REST-Servere er Delphi dog også særdeles velegnet, især når det handler om genbrug af eksisterende faglogik eller om performante services. Typiske anvendelsesområder i B2B-miljøer:

• API-lag for bestående software: Den eksisterende Delphi-fagapplikation bevares som UI, mens REST-Serveren kapsler dataadgang og regler for nye forbrugere.
• Backend for portal-/kundeområde: Web-portal bruger REST-endpoints, der anvender samme regelkerne som interne processer.
• Integrations- og interface-server: ERP/DMS/CRM-tilslutning, import/export, event-behandling, tidsstyrede jobs.
• Linux-Services eller Windows-Services: Langløbende processer, queue-workers, scheduler, dokumentworkflows.

Afgørende er ikke så meget framework-betegnelsen, men disciplinen i lagdeling, samtidighedsstyring, fejlhåndtering og deployment. Delphi tillader begge dele: hurtige leverancer og samtidig ren, modulær arkitektur – hvis man planlægger bevidst.

Schichtenmodell: Layer-3 arkitektur som grundlag for langtidsholdbare APIs

Til virksomhedsoftware har et klart, slankt lagdelt model vist sig robust. I Delphi-miljøet beskrives det ofte som Layer-3 arkitektur. Begreberne varierer, men ansvaret bør være entydigt:

1) API-/Transport-lag (HTTP, serialisering, routing)

Dette lag håndterer HTTP, protokolniveau-autentifikation, request/response-formater, routing, statuskoder, Content-Type og komprimering. Faglige regler hører ikke hjemme her. Målet: udskiftelighed og testbarhed. Hvis I senere vil udvide fra en REST-API til supplerende protokoller (fx WebSocket, gRPC-lignende mønstre, Server-Sent Events), skal fagkernen være stabil.

2) Domæne-/Service-lag (faglogik, use cases, rettigheder, transaktioner)

Her ligger den faglige sandhed: tilstandsmaskiner, beregninger, plausibiliteter, klientregler, rettighedstjek ved faglige handlinger. Dette lag bør være UI-uafhængigt og i videst muligt omfang uden kendskab til HTTP. Ideelt implementerer I use cases som „frigiv ordre“, „luk ticket“, „opret faktura“ i stedet for blot CRUD på tabeller.

3) Data-Access-lag (repositories, SQL, FireDAC, mapping)

Dette lag kapsler persistens: SQL, stored procedures, transaktionsstyring, låse-, connection-pooling og DB-specifikke særheder. I Delphi er BDE-Ablosung mit nativer Anbindung ofte et pragmatisk valg, især ved migrationer (BDE-Ablösung) og ved heterogene databaser (SQL Server, PostgreSQL, MariaDB, Firebird). Vigtigt er, at Data-Access-laget ikke har HTTP-viden og ikke træffer forretningsmæssige beslutninger.

Modellen reducerer koblingen: ændringer i datamodellen tvinger ikke til omskrivning af APIen, og nye klienter arver automatisk den samme logik. Især i Delphi Modernisierung er dette fundamentet for at frakoble etablerede desktop-applikationer trinvis uden at afbryde driften.

API-design for virksomhedsoftware: Ikke CRUD, men faglige kontrakter

Mange APIs starter med endpoints som /customers, /orders, /documents og implementerer CRUD. Det kan være tilstrækkeligt for interne værktøjer, men i virksomhedsoftware bliver det hurtigt for overfladisk. Fagprocesser består af tilstandsændringer, regler, sideeffekter og rettigheder.

Modeller ressourcer, handlinger og tilstande konsekvent

Et bedre mønster er kombinationen af ressourcer og klare handlinger, fx:

• Læs ressource: GET /orders/{id}
• Udløs handling: POST /orders/{id}/release
• Opret dokument: POST /orders/{id}/documents/invoice
• Tjek status: GET /orders/{id}/status

Dermed bliver API-kontrakten tydelig: „frigivelse“ er ikke blot en opdatering af et felt. Serveren kan centralt implementere valideringer, rettigheder, transaktioner, audit og sideprocesser.

Fejlesemantik og validering: gør det planbart for klienter

Virksomhedsklienter skal kunne skelne fejltyper: valideringsfejl (400), manglende rettighed (403), konflikt pga. parallel ændring (409), faglig afvisning (ofte også 409 eller 422), midlertidige backend-problemer (503). Vigtigt er en konsekvent fejlstruktur, fx med fejlcode, message, valgfrie feltangivelser og en korrelations-ID. Så kan et portal vise forståelige beskeder og samtidig gøre support og drift effektive at følge op på.

Sikkerhed: autentifikation er ikke det samme som autorisation

I B2B-kontekster fejler sikkerhed sjældent på kryptering, men på manglende adskillelse af identitet, roller og faglige rettigheder. En REST-Server-arkitektur skal derfor adskille to niveauer:

Autentifikation (hvem er det?)

Typiske metoder er token-baserede tilgange (fx JWT eller opaque tokens), kombineret med TLS og en klar sessionstrategi. Afgørende er: token-levetid, refresh-mekanisme, mulighed for at spærre tokens ved rolleændringer, og om portaler og interne systemer bruger forskellige Identity Providers. Delphi-Servere kan både agere Resource-Server og – afhængig af setup – udstede tokens. I mange virksomhedsmiljøer er integration med eksisterende identity-systemer (fx AD/LDAP, SSO-løsninger) et centralt punkt.

Autorisation (må han det?)

Autorisation hører hjemme i Domæne-/Service-laget. Roller og rettigheder er sjældent kun tekniske; de afhænger af tenant, lokation, organisatorisk enhed, kontraktstatus eller procesfase. God praksis:

• Rollemodel (fx Admin, Sagsbehandler, Auditor) som basis
• Faglige policies („må kun oprette faktura i status X“, „må kun se egne tickets“)
• Mandantisolering som standard: hver request skal indeholde tenant-kontekst
• Auditing: hvem udførte hvilken handling hvornår

APIen bør ikke kun returnere „adgang tilladt/afvist“, men konsekvent forhindre, at parametriske tricks afslører data fra andre tenants. Det lyder selvfølgeligt, men i ældre systemer er det en af de hyppigste arkitekturfejl, når man for hurtigt „lægger tabeller på HTTP“.

Dataadgang med FireDAC: transaktioner, pooling og database-strategi

I virksomhedsapplikationer er dataadgang stabilitetsnøglen: belastningstoppe, deadlocks, lange reports, parallelle updates, batch-importer. FireDAC er i Delphi-økosystemet en velafprøvet komponent til at betjene forskellige databaser med ensartet adgang. For en REST-Server-arkitektur er især følgende punkter afgørende:

Transaktionsgrænser per use case

En REST-API er typisk request-baseret. Det passer godt til „transaktion per use case“: Inden for et request åbnes en transaktion, faglige operationer udføres, herefter commit/rollback. Vigtigt: pak ikke automatisk hvert endpoint ind i en transaktion, men vær konsekvent ved skrivende handlinger. Læseendpoints kan afhængig af isolation level også kræve transaktioner, hvis konsistente views er vigtige.

Connection-strategi og parallelitet

Server-parallelitet betyder: mange samtidige requests, hver med DB-adgang. Planlæg derfor:

• begrænsede, overvågede poolstørrelser
• time-outs for queries og forbindelser
• klare regler for langløbende operationer (outsourcér til jobs/workers)

En almindelig fejl er at køre dyre reports eller massedata-eksport synkront i den samme API-instans, som betjener interaktive portal-forespørgsler. Bedre er separation: interaktivt vs. batch/async.

Databasemodernisering som del af API-planen

Hvis der i det bestående stadig findes ældre dataadgange (fx BDE), bliver APIen en katalysator: den tvinger til klare dataadgangsgrænser. En kontrolleret Ablösung mod FireDAC reducerer risici og øger portabiliteten (PostgreSQL, MariaDB, SQL Server). Vigtigt er ikke at planlægge et „Big Bang“, men at gøre det trinvist: nye server-use-cases bruger allerede det nye Data-Access-lag, mens legacy-komponenter følger efter.

Versionering og bagudkompatibilitet: API-kontrakter beskytter

Virksomheder undervurderer ofte, hvor kostbare Breaking Changes er. Når et kundeportal, et partner-system eller en Windows- und Linux-Services bygger på jeres API, kan I ikke længere „lige hurtigt“ omdøbe felter. En klar versioneringsstrategi er derfor obligatorisk.

Pragmatiske regler for versionering

• Ingen Breaking Changes uden version: felter må ikke omdøbes/fjernes, endpoints må ikke ændres i betydning.
• Udvid frem for at ændre: tilføj nye felter, marker gamle som deprecated.
• Kompatible defaults: undgå nye obligatoriske felter eller udled dem server-side.
• Eksplicit versionering: fx /v1/… eller via headers; vigtigere end metoden er konsekvens.

For Delphi-teams betyder det også: hold DTOs (Data Transfer Objects) stabile og design mapping bevidst i stedet for at serialisere domæneobjekter 1:1. Det øger indsatsen i starten, men reducerer supportomkostningerne på lang sigt.

Observability: logs, metrikker og traces planlagt fra starten

I produktiv drift er „det virker hos mig“ værdiløst, hvis fejl ikke kan reproduceres. Særligt REST-Servere, der betjener mange forbrugere, har et minimumskrav til observability:

Struktureret logging med korrelations-ID

Hver request bør bære en korrelations-ID (enten videreføres den eller genereres) og fremgå i logfiler. Logposter bør være strukturerede (fx JSON-log), så de kan ingestes i centrale systemer. Minst relevant:

• request-metode, route, statuskode, varighed
• bruger-/tenant-kontekst (pseudonymiseret/regelkompatibelt)
• DB-varighed og fejlklasse
• korrelations-ID for support

Metrikker for kapacitet og fejltrends

Til skalering og stabilitet behøver I metrikker: requests per minut, p95/p99-latens, fejlrate per endpoint, DB-pool-udnyttelse, queue-længder. Det behøver ikke være „cloud-native overkill“, men uden tal bliver performance-diskussioner subjektive.

Fejl- og exceptionhåndtering som arkitekturkomponent

Delphi-exceptions må ikke falde ukontrolleret igennem til klienten. En central exception-middleware (eller global handler) bør oversætte exceptions til konsistente fejlresponser, inklusive support-ID og meningsfulde HTTP-koder. Internt hører stacktraces i sikre logs, ikke i klientresponser.

Synkront vs. asynkront: flyt langløbende arbejde ud af REST-svaret

Mange virksomhedsprocesser er ikke „request/response på 200 ms“: PDF-generering, dataimport, interface-kørsler, afstemninger, masseændringer, arkivering. Sådanne arbejdsbelastninger hører sjældent hjemme i et synkront REST-endpoint, fordi de binder tråde, forårsager timeouts og blokerer brugere.

Job-mønster

En velafprøvet tilgang er: et endpoint starter et job, serveren returnerer straks en job-ID. Et andet endpoint leverer status/resultat. Valgfrit kan et callback/webhook underrette. I Delphi kan det implementeres med worker-services, en job-tabel og en klar statusmaskine. Fordelen er stabilitet og planbar skalering.

Queues og services

Afhængig af miljø kan en message queue være nyttig, men det er ikke altid nødvendigt. Vigtigt er princippet: interaktive APIs forbliver responsive, batch-processer kører kontrolleret, gentageligt og observerbart – som Windows-services eller Linux-services, afhængig af deployment.

Deployment i virksomheder: Windows, Linux, containere, on-prem

En REST-Server-arkitektur er først „færdig“, når den er driftsbar. Virksomheder adskiller sig meget: klassiske Windows-servere, virtualiserede Linux-hosts, containerplatforme, strenge netværkszoner, proxy- og certifikatkrav. Delphi er her fleksibel, så længe afhængigheder styres klart.

Konfiguration og secrets

Konfiguration skal være miljøafhængig (Dev/Test/Prod). Adgangsdata hører ikke i EXE eller repository. Brug sikker opbevaring (fx platformens secrets-management) og adskil konfigurationsværdier fra kodeudgivelser. Planlæg også rotationer (DB-adgangskode, API-keys) uden at skulle bygge systemet om.

Release- og rollback-strategier

Når flere forbrugere benytter en API, har I brug for kontrollerede releases: migrationsskripter til DB-ændringer, feature-toggles til trinvis aktivering, klare rollback-veje. Især databaseændringer skal være bagudkompatible, så et rollback af serverversionen forbliver muligt.

Integration med bestående software: trinvis modernisering frem for Big Bang

I mange Delphi-landskaber er den faglige kerne værdifuld, men teknisk „limet fast“: UI-nære dataopslag, globale tilstande, blandede ansvarsområder. En REST-API kan både være risiko og mulighed. Målet bør være en vej, der med overkommelige midler leverer målbare forbedringer.

Strangler-tilgang for APIs

I stedet for at omskrive alt definerer I faglige grænseflader, der leverer reel værdi: fx „ordrestatus og dokumenter til kundeportal“, „stamdata-lookup for mobile brugere“, „interface til ERP-bogføringer“. Disse use cases implementeres som nye API-funktioner inklusive domænelag og dataadgang. Den gamle klient kan trinvis skifte til de samme server-use-cases uden at UI behøver genopbygges med det samme.

Fælles faglogik: nyttigt, men kontrolleret

Delphi muliggør, at faglige biblioteker bruges både på server og i eksisterende applikationer. Det kan være en bro, men det indebærer risici: hvis UI-afhængigheder siver ind i den fælles logik, mister I entkoblingen. En klar regel hjælper: kun logik uden UI, uden globale tilstande, med klare interfaces og testbare enheder må deles. Alt andet holdes adskilt.

Typiske fejl i REST-Server-projekter – og hvordan man undgår dem

„Vi publicerer bare tabeller”

Hvis endpoints spejler tabeller direkte, opstår et ustabilt system: hvert DB-refaktorering bliver et API-breaking-change, faglige regler duplikeres i klienter, og sikkerhedshuller via ufiltrerede parametre er mere sandsynlige. Bedre: domæne-use-cases og DTOs, der stabiliserer kontrakten.

Faglige rettigheder kun i klienten

Klienter er udskiftelige og manipulerbare. Autorisation hører i serveren og må tage faglige regler i betragtning, ikke kun tekniske roller.

Ingen klar strategi for samtidighed

Parallelle opdateringer sker: to sagsbehandlere, portal og intern klient, eller et importjob. Uden Optimistic Locking (fx RowVersion/Timestamp), konfliktkoder (409) og klare merge-regler opstår datatab eller „sidste skriver vinder“-fejl.

Langløbere blokerer interaktive endpoints

Synkron PDF-generering eller eksporter fører til timeouts og „hænger“-oplevelser. Job-mønsteret med status-endpoints er bedre.

Observability klaskes på i efteråret

Uden korrelations-ID, strukturerede logs og metrikker bliver hver forstyrrelse en detektivopgave. Observability er ikke luksus, men en forudsætning for drift.

Konkrete tjekpunkter for jeres REST-Server-arkitektur med Delphi

• Adskil lagene klart: Transport (HTTP), Domæne (Use Cases), Data Access (FireDAC/SQL).
• Forstå APIen som kontrakt: hold DTOs stabile, planlæg versionering, undgå Breaking Changes.
• Sikkerhed i to lag: Autentifikation (tokens) plus autorisation (faglige policies, tenant).
• Transaktioner bevidst: per use case, timeouts, konfliktstrategi.
• Langløbere som asynkrone jobs: Workers/Jobs, Windows- eller Linux-services.
• Indbyg observability: korrelations-ID, strukturerede logs, metrikker, central fejlhåndtering.
• Planlæg deployment realistisk: konfiguration/secrets, rollback, databasemigrationer.
• Modernisering iterativt: værdiskabende use cases først, legacy-komponenter løbende afkobles.

Konklusion: REST-Servere udfolder deres værdi først som drifts- og fagarkitektur

En REST-Server-arkitektur med Delphi er særligt effektiv for virksomheder, når den ikke opfattes som et „teknisk lag“ alene, men som den forbindende kerne mellem processer, data og kanaler. Afgørende er rene lag (Layer-3 arkitektur), fagligt modellerede endpoints, konsekvent sikkerheds- og tenantlogik samt et driftskoncept med versionering, monitoring og kontrolleret samtidighed. Så bliver APIen en stabil platform: for portaler, integrationer, services og den trinvise Delphi Modernisierung – uden at sætte den faglige substans i et vokset system over styr.

Hvis I vil undersøge, hvordan en robust REST-API kan etableres på jeres eksisterende Delphi-landskab (inkl. databasstrategi, FireDAC, services og drift), kan I kontakte os her: https://net-base-software-gmbh.de/kontakt/