Udvikling af REST-servere med Delphi: arkitektur, sikkerhed og drift i praksis

Den, der vil udvikle en REST-Server med Delphi, har i virksomheder sjældent et mål i sig selv. Som regel handler det om pålidelige grænseflader mellem eksisterende systemer, portaler, tjenester og databaser – med klare krav til drift, sikkerhed og vedligeholdelse. Det afgørende er ikke, hvor hurtigt det første endpoint svarer, men om servicen forbliver stabil i daglig drift: efterprøvelige fejlbilleder, kontrollerede dataadgange, ren autentificering, klare ansvarsfordelinger i arkitekturen og en deployment, der passer til Windows- og Linux-miljøer.

Delphi er i mange organisationer et pragmatisk valg: eksisterende faglogik kan genbruges, ydelsen er som regel tilstrækkelig, og der findes flere måder at realisere HTTP-baserede APIs på. I praksis adskiller mulighederne sig mindre i „kan REST“, og mere i transparens og drift: Hvor konsistent kan logging, timeouts, reverse-proxy-regler, versionering, OpenAPI-dokumentation og sikkerhedsmekanismer gennemføres?

Denne artikel placerer de vigtigste Delphi-tilgange og viser, hvad IT-ledelse, administratorer og tekniske projektansvarlige bør være opmærksomme på: fra API-design over security og BDE-afløsning med native tilkobling-dataadgang til observability (logs, metrics, tracing) og deployment som Windows- eller Windows- og Linux-Services. Målet er et robust grundlag for integrationer til ERP, DMS, CRM eller kundeportaler – uden at gøre framework-interna til fokus.

Hvornår et REST-Server med Delphi særligt giver mening

Et Delphi-REST-backend er ofte fornuftigt, når Delphi allerede er forankret i virksomheden, eller når faglogik og dataadgang fra eksisterende applikationer skal genbruges. Typiske B2B-situationer:

• Gøre bestående software API-klar: En VCL-applikation eller en client-server-kerne får et REST-lag, så portaler, eksterne systemer eller interne tjenester kan tilgå standardiseret.
• Integration og afkobling: Flere consumers (desktop, web-portal, batch, partner) skal anvende de samme forretningsprocesser uden direkte databaseadgang eller filbaserede integrationer.
• Modernisering i etaper: Først indføre en stabil API, dernæst UI, moduler eller database i kontrollerede skridt. API’en bliver en kontrolleret grænseflade og reducerer sideeffekter.
• Drift og security: HTTP-APIs er velegnede til drift bag reverse proxies, central autentificering og integration i overvågnings-stacks.

Vigtigt er forventningsafstemningen: REST er et integrationslag, ikke en erstatning for faglig konsistens. Starter man uden klart domænemodel, definerede transaktionsgrænser eller tydeligt dataansvar, ender man nemt med en API, der er tilgængelig, men dyr at vedligeholde og supportere på sigt.

REST-Servere med Delphi: oversigt over muligheder

Delphi tilbyder flere veje til en REST-service. For beslutningstagere er spørgsmålet mindre hvilket der er mest „moderne“, og mere hvordan det passer til teamstruktur, driftsmodel, levetid og compliance-krav.

Delphi WebBroker: slankt, transparent, velkontrolleret

WebBroker er et etableret Delphi-framework til HTTP-applikationer. Det er tæt på protokollen (request/response), hvilket gør det let at gennemskue og attraktivt i mange B2B-scenarier, hvor kontrolleret fejlhåndtering, korrekt header-håndtering og et overskueligt stack er vigtige. WebBroker kan typisk køres effektivt bag en reverse proxy, der terminerer TLS og håndhæver centrale sikkerhedsregler.

Konsekvensen i praksis: Mange komfortfunktioner (routing-konventioner, middleware-kæder, vedligeholdelse af OpenAPI) må tilføjes struktureret. Det er ikke et minus, hvis arkitekturstandarder i forvejen er prioriterede.

Delphi Horse: routing og middleware for klare API-standarder

Delphi Horse er letvægts og bygger på eksplicit routing kombineret med et middleware-princip. Middleware betyder her: genanvendelige behandlingssammenhænge „omkring“ endpointet, fx autentificering, logging, rate limits eller request-validering. Det er for mange teams en produktiv tilgang, fordi standarder kan håndhæves centralt.

For driften er det vigtigt at definere tidligt et ensartet fejlfomat, timeouts, maksimale request-størrelser og en logging-standard. Uden sådanne retningslinjer forbliver systemet funktionelt, men bliver unødigt tungt i support og ved videreudvikling.

RAD Server: platformtilgang med integrerede komponenter

RAD Server (tidligere EMS) følger en platformtilgang med indbyggede funktioner som brugeradministration og andre byggesten. Det kan passe, når flere clients deler et backend og platformfunktionerne ønskes udnyttet. Til rene integrations-APIs er det ikke automatisk det bedste valg; her vægtes ofte transparens, lave afhængigheder og et slankt driftsscenarie højere.

DataSnap: vurdér eksisterende installationer realistisk

DataSnap er historisk til stede i mange Delphi-landskaber og kan eksponere HTTP/REST-lignende endpoints. Til nye initiativer bør man dog vurdere, om det matcher det ønskede API-stil, autentificering (fx JWT), OpenAPI/Swagger og moderne driftskrav. En pragmatisk vej er ofte at genbruge eksisterende logik internt, men udadtil implementere et klart defineret REST-API-lag, som håndhæver standarder for security, logging og versionering.

Arkitektur, der bærer i drift og vedligehold

En hyppig fejl i REST-projekter er „handleren gør alting“: HTTP-parametre læses, SQL bygges direkte, forretningsregler implementeres, og logging tilføjes løbende. Det virker hurtigt i starten, men fører til svært testbar kode og ustabile ændringer.

I virksomhedsopsætninger slår en klar lagdeling ofte igennem. En pragmatisk, udbredt struktur er en Layer-3-arkitektur (tre lag), der adskiller ansvarsområder:

Transportlag: HTTP, auth, validering, svarformat

Her accepteres requesten, grundlæggende validering foretages, og et konsistent svarformat fremstilles. Dette lag håndterer også autentificering og autorisation (hvem må hvad) samt tekniske regler som request-limits, CORS eller tildeling af correlation-IDs (entydige IDs pr. anmodning til sporing).

Domænelag: faglige use-cases fremfor endpoint-logik

Domænet kapsler faglige processer som „opret ordre“, „ændr status“ eller „knyt dokument“. Vigtigt: denne logik bør være mest muligt uafhængig af HTTP-frameworket. Så kan samme domæne også bruges af en Windows- og Linux-Service, en Linux-daemon eller et batch-job uden at duplikere logik.

Persistens og integration: FireDAC, database, ERP/DMS/SMTP

Dette lag samler adgang til databaser og eksterne systemer. For Delphi er BDE-Ablosung mit nativer Anbindung den gængse dataadgangsstack til at forbinde PostgreSQL, SQL Server, MariaDB/MySQL eller Firebird på en robust måde. Væsentligt er ikke blot at „bruge FireDAC“, men at fastsætte bindende regler: connection-håndtering, transaktionsgrænser, timeouts, parameterbinding, oversættelse af tekniske fejl til API-fejlkoder og ensartede retry-strategier, hvor det fagligt giver mening.

API-design: stabilt over år, ikke kun til Go-live

I B2B-miljøer er en API en løbende vedligeholdt grænseflade. Nøglebegrebet er kompatibilitet: Consumers baserer sig på felter, statuskoder og semantik. Jo tydeligere reglerne defineres, desto mindre arbejde i integration, support og release-håndtering.

Ressourcer og stier: konsistens fremfor kreativitet

Stabile APIs er typisk ressourcerettede: „/customers“, „/orders/123“, „/orders/123/items“. Proces-aktioner kan modellere som sub-ressourcer eller velbegrundede action-endpoints, fx „/orders/123/cancel“, når et rent CRUD-mønster ikke dækker. Det afgørende er en ensartet konvention, der dokumenteres og bruges på tværs af teamet.

HTTP-metoder og statuskoder: klare signaler til consumers

En API bliver let at integrere, hvis den bruger forventet HTTP-semantik: GET til læsning, POST til oprettelse, PUT/PATCH til ændringer, DELETE til sletning. Lige så vigtigt er et konsistent fejladfærd. Til drift er et standardiseret fejlobjekt nyttigt med:

• HTTP-status (fx 400, 401, 403, 404, 409, 422, 500)
• stabil fejlkode (maskinlæselig, dokumenteret)
• Correlation-ID (til hurtig kobling i logs)
• valgfri detaljer (fx feltfejl ved validering)

Et tilbagevendende problem er svar med „200 OK“ og fejltekst i body. Det gør integrationer sværere og fører til fejlbehæftet klientlogik.

Versionering og kompatibel udvidelse

Versionering er et proces- og kommunikationsspørgsmål, ikke kun et teknisk valg. Almindelige tilgange er URL-versionering (fx „/api/v1“) eller header-baseret versionering. I mange virksomheder er det vigtigste princip dog: udvide kompatibelt. At tilføje nye felter er oftest ufarligt; at fjerne eller genfortolke felter kræver ny version og et klart kommunikeret migrationsvindue. Det reducerer integrationsafbrydelser og gør releases planbare.

Sikkerhed: autentificering, autorisation, angrebsflader

En REST-service er et potentielt angrebspunkt. Mange sikkerhedsproblemer opstår ikke på grund af manglende kryptering, men pga. små detaljer: for brede rettigheder, for lange token-levetider, ubeskyttede admin-endpoints, ukontrollerede CORS-regler eller logs med følsomme data.

TLS og reverse proxy: klare ansvar i netværket

I typiske opsætninger termineres TLS i reverse proxyen (fx Nginx, Apache eller Microsoft IIS som reverse proxy). Delphi-servicen kører internt på HTTP og er kun tilgængelig fra det interne net. Vigtige pointer er korrekte regler for „X-Forwarded-For“ og „X-Forwarded-Proto“, så client-IP og protokol kan fortolkes rigtigt. Disse oplysninger er relevante for audit, rate limiting og fejlsøgning.

JWT, API-Keys og SSO: hvad der passer i praksis

Til system-til-system-integrationer er API-Keys eller client-credentials-mechanismer udbredte. Til brugeradgang i virksomhedslandskabet er JWT (JSON Web Token) ofte praktisk i kombination med en central Identity Provider (fx OIDC). I SSO-landskaber kan også SAML 2.0 være relevant (en standard for Single Sign-on, typisk mellem portal/gateway og Identity Provider).

Uanset metode bør I definere:

• Nøgle- og certifikatrotation (hvordan fornyes signaturer?)
• Roller/Scopes (hvilke rettigheder gælder for hvilke endpoints?)
• Multitenancy (hvordan håndhæves tenant-tilknytning korrekt?)
• Audit-logging (hvem udførte hvilken faglig handling og hvornår?)

Input-validering, CORS og rate limiting

Input-validering bør ske i flere lag: syntaktisk (datatyper, JSON-struktur), fagligt (værdierum, statusovergange) og security-relateret (filnavne, stier, headers). For browser-klienter er CORS væsentligt (regler for hvilke origins og headers der er tilladt). CORS bør konfigureres restriktivt. Rate Limiting beskytter mod misbrug og belastningstoppe; det implementeres ofte i reverse proxy og suppleret med server-side grænser (maksimal body-størrelse, timeouts, begrænset parallelitet).

FireDAC og databaseadgang: stabilitet gennem regler

I REST-backends er databaseadgangen ofte den dominerende faktor for latenstid og stabilitet. FireDAC tilbyder de tekniske muligheder, men driftssikkerhed opnås via styrende retningslinjer.

Connection-håndtering og samtidighed

En klassisk fejl er en globalt delt databaseforbindelse, som bruges parallelt af flere requests. I en REST-Server med parallel behandling (threads/workers) skal det være klart, hvilke objekter er trådsikre, og hvilke ikke er. I praksis betyder det: håndter forbindelser og query-objekter per request eller per unit-of-work, eller benyt kontrolleret pooling afhængigt af servermodellen. Det reducerer deadlocks, sporadiske fejl og svært reproducerbare problemer.

Transaktioner langs use-cases

Transaktioner hører hjemme i domænet: En use-case afgør, hvad der hører atomisk sammen. Ofte er „en request = en transaktion“ fornuftigt, men ikke altid. Read-only endpoints behøver typisk ikke eksplicit transaktion, mens skriveflows kan kræve konsistente ændringer på tværs af tabeller. Ved eksterne integrationer (ERP, DMS, webhooks) er distribuerede transaktioner ofte urealistiske; her hjælper klare rækkefølger og kompensationslogik (hvordan håndteres delvise succeser?).

Timeouts, backpressure og kontrolleret fejlslag

Uden timeouts hober anmodninger, tråde og DB-forbindelser sig op. Sæt derfor timeouts på HTTP- og DB-niveau. Supplerende er backpressure vigtigt: begræns parallelitet og kølængder, så systemet under belastning kan reagere kontrolleret med 503 (Service Unavailable) i stedet for at gå ned som følge af ressourceudtømning. Til drift er et hurtigt, klart fejlbillede at foretrække frem for minutlange låsninger.

Payloads, DTOs og langsigtet kompatibilitet

JSON er standard, men interoperabilitet afgøres af detaljer: dato-/tidsformat, tidszoner, null-værdier, decimalrepræsentation, feltnavne og encoding. Fastlæg en standard (fx ISO-8601 i UTC) og hold den konsekvent.

DTOs fremfor database-strukturer

DTOs (Data Transfer Objects) er API-datamodeller optimeret til udveksling. De bør ikke blot spejle databasen. Dermed undgår man, at interne schemaændringer øjeblikkeligt medfører API-brud. Samtidig kan man styre, hvilke interne felter der ikke må eksponeres (fx flags, audit-kolonner) og hvordan intern refaktorering kan ske uden at påvirke integrationer.

Idempotens og retries

Timeouts og retries er normale i virksomhedsnetværk. Definér hvilke operationer der er idempotente (gentagen udførelse giver samme resultat) og hvordan dobbelte POSTs undgås, fx via et idempotency-key for udvalgte skriveoperationer. Det reducerer dubletter, inkonsistente tilstande og supporttilfælde.

Dokumentation og tests: OpenAPI som fælles arbejdsbasis

En API bruges i B2B sjældent kun af ét team. OpenAPI (Swagger) er et praktisk fælles sprog, fordi specifikationer kan automatiseres: client-generering, mocking, contract-tests og diffing mellem versioner. Selv om Delphi-stacken ikke altid genererer alt automatisk, er en vedligeholdt specifikation et centralt artefakt.

Pragmatisk testdækning, der sænker driftsomkostninger

En fornuftig teststruktur for REST-services består typisk af tre niveauer:

• Unit-tests for domænelogik (uden HTTP, uden database)
• Integrationstests for dataadgang og transaktionsadfærd (med testdatabase og reproducerbare seed-data)
• API-/Contract-tests mod en kørende service (statuskoder, auth, fejlformater, versionering)

For administratorer og driftsteams er det afgørende, at tests er reproducerbare og ikke knyttet til udviklermiljøer. Jo tættere testmiljøet ligner det endelige deployment, desto færre overraskelser ved opdateringer.

Deployment og drift: Windows-Service, Linux-Service, container

En REST-server anses i praksis først for „færdig“, når den kan drives stabilt: start/stop-adfærd, log-rotation, opdateringer, rettigheder, portåbninger, certifikater, overvågning og klare rollback-muligheder.

Windows- og Linux-Services: velafprøvede driftsmodeller

Under Windows er drift som et Windows- und Linux-Services ofte oplagt, fordi der findes mekanismer for starttype, recovery, rettigheder og overvågning. Under Linux anvendes ofte en systemd-tjeneste (systemd er standard service-manager), som styrer restart-politikker, logging-integration og startsekvenser. For begge verdener gælder: en reverse proxy foran forenkler TLS, header-politikker, rate limits og routing.

Container: reproducerbart, men kun med klar state-separation

Containere kan ensarte deployment og accelerere rollouts. Forudsætningen er klar adskillelse af state: ekstern database, filer i volumes, secrets via secret-management. Uden disse principper opstår svære at vedligeholde blandtilstande, som viser sig ved driftsproblemer eller restore-scenarier.

Konfiguration: efterprøvelig, miljøopdelt, uden secrets i repo

Et konsistent konfigurationsmønster hjælper: adskilte settings for dev/test/prod, central definition af log-niveauer, DB-forbindelsesdata, timeouts, tilladte origins og token-nøgler. Følsomme oplysninger hører ikke i kildekode-repositoriet. Til audits og drift er det vigtigt, at konfigurationsændringer kan spores og rulles ud kontrolleret.

Observability: logs, metrics og tracing som driftsforudsætning

Når integrationer hænger, skal driftsteamet have svar: hvilke endpoints er berørt, siden hvornår, med hvilken fejlrate, og hvilken afhængighed er langsom? Uden observability bliver hver hændelse manuel detektivarbejde.

Struktureret logging og Correlation-IDs

Struktureret logging (key/value eller JSON) muliggør analyser i værktøjer og gør det lettere at filtrere efter endpoint, tenant, fejlkode eller Correlation-ID. Hver request bør tildeles en Correlation-ID, som også returneres i Response-header. Følsomme data som adgangskoder, tokens eller personoplysninger må ikke logges; her hjælper maskering, hashing eller målrettede debug-logs i isolerede miljøer.

Metrikker for kapacitet og stabilitet

Praktisk nyttige metrikker er request-rate, latenser (fx p95/p99), fejlrater pr. endpoint, DB-tider, antal aktive workers/threads, connection-udnyttelse og kø-længder. Disse værdier ligger til grund for kapacitetsplanlægning og hjælper med at opdage gradvise problemer (manglende indekser, nye afhængigheder, ugunstige forespørgselsveje).

Moderniseringsvej: REST som stabil grænse for voksende Delphi-systemer

I mange Delphi-landskaber er REST-API’en ikke endestationen, men et stabiliserende og moderniserende element. En velafprøvet, lavrisiko fremgangsmåde er trinvis:

1. Prioriter use-cases: Hvilke funktioner skal eksternt være tilgængelige (stamdata, statusændringer, dokumentadgang, godkendelser)?
2. Fastlæg API-standarder: auth, fejlformat, versionering, logging, timeouts, rate limits, OpenAPI.
3. Ekstraher domænet: strukturer faglogik, så den ikke er bundet til UI eller enkelte endpoints.
4. Konsolider dataadgang: FireDAC-regler, transaktionskoncept, performance-baselines, query-politikker.
5. Migrér consumers etapevis: desktop, portaler og andre services bruger API’en; direkte DB-adgange reduceres.

Resultatet er et system, der kan udvikles etapevis: moduler kan udskiftes uden, at ændringer ukontrolleret påvirker alle clients.

Typiske faldgruber i B2B-REST-projekter

Nogle fejlbilleder går igen og kan undgås med klare regler:

• Uensartede fejlformater: Support og integration vanskeliggøres. Løsning: standardiseret fejlobjekt med stabile fejlkoder.
• Security som efterskrift: Roller, multitenancy og audit tilføjes „senere“. Løsning: planlæg det som grundstruktur, ikke improviser per endpoint.
• Ingen limits: manglende body-limits, timeouts og parallelitetsgrænser fører til nedbrud under belastning. Løsning: reverse proxy plus server-side backpressure.
• Database for tæt koblet til API: Hver schemaændring bryder consumers. Løsning: DTOs og klart definerede use-cases.
• For lidt observability: Problemer kan ikke måles. Løsning: Correlation-IDs, strukturerede logs, kerne-metrikker.

Konklusion: REST med Delphi betyder ansvar for grænseflade og drift

At udvikle en REST-server med Delphi er i virksomhedsopsætninger bæredygtigt og succesfuldt, når arkitektur og drift planlægges sammen fra starten. Valget af framework (WebBroker, Horse, RAD Server eller en migrationsvej fra DataSnap) er relevant, men ikke den største løftestang. Det afgørende er klare standarder for API-design, autentificering, fejlhåndtering, versionering, FireDAC-dataadgang, timeouts samt observability og deployment som Windows- eller Windows- und Linux-Services. Så bliver grænsefladen et stabilt integrationsbyggesten, der muliggør modernisering i stedet for at blokere den.

I det faglige miljø spiller også Delphi REST-API og Delphi REST-API und REST-Server en vigtig rolle, når integrationer, dataflow og videreudvikling skal spille sammen.

Projekt eller moderniseringsprojekt med Net-Base drøfte.