REST-palvelinarkkitehtuuri Delphillä yrityksille

Monet yritykset ovat nykyään samanlaisen lähtökohdan edessä: kasvanut toiminnallinen sovellus (usein Delphi/VCL) kattaa keskeiset prosessit, mutta sen pitää yhtäkkiä palvella uusia kanavia. Asiakasportaali tarvitsee tietoja ja tapahtumia, mobiilikäyttäjät odottavat turvallisia pääsyjä, kolmannen osapuolen järjestelmät (ERP, DMS, CRM, BI) vaativat integraatioita. Tässä tilanteessa REST-API vaikuttaa luonnolliselta askeleelta. Käytännössä API-aloitteet eivät kuitenkaan yleensä kaadu HTTP:hen tai JSON:iin, vaan epäselvään vastuunjakoon clientin, serverin ja tietovarannon välillä.

Kestävä REST-Server-arkkitehtuuri yhdessä Delphi:n kanssa ei synny sillä, että „muutama endpoint“ peitetään olemassa olevien tietokantataulujen päälle. Se muodostuu, kun yritys tarkastelee yhdessä toiminnallisia sääntöjä, turvallisuusvaatimuksia, datan omistajuutta, transaktiorajoja ja käyttökonsepteja. REST-serveristä tulee tällöin vakaa sopimuskerros liiketoimintalogiikan ja kuluttajien välille: työpöytäsovellus, portaali, palvelut, rajapintakumppanit. Tässä Delphi korostaa vahvuuksiaan: nopea kehitys, vakaa ajoaika, suorituskykyinen natiivikoodi, hyvä tietokantaintegraatio (esim. BDE-korvaus natiiviliitännällä) ja mahdollisuus kapseloida liiketoimintalogiikka hallitusti kirjastoihin tai palvelinmoduuleihin.

Tässä kirjoituksessa kuvataan, miten yritykset voivat suunnitella REST-Server-ratkaisut Delphi:lla siten, että ne pysyvät toiminnallisesti yhdenmukaisina, liittyvät olemassa oleviin järjestelmämaisemiin ja eivät aiheuta käyttöön vakavia virhelähteitä. Keskitymme arkkitehtuuriperiaatteisiin, tyypillisiin modernisointiprojektien sudenkuoppiin sekä konkreettisiin osiin turvallisuudessa, datan käytössä, versionhallinnassa ja havaittavuudessa.

Miksi REST-API on yrityksessä arkkitehtuuripäätös

Perinteisessä client-server-maailmassa monet säännöt olivat implisiittisesti hajautettuja työpöytäasiakasohjelmaan: validoinnit, tilamuutokset, laskelmat ja osittain jopa oikeudet. Niin kauan kuin käytössä oli vain yksi asiakas, se oli hallittavissa — toiminnallisesti epäsiistiä, mutta kontrolloitavissa. Kun useampi kuluttaja pääsee käsiksi samoihin liiketoimintakohteisiin, malli kärsii:

• Portaali ei voi „uudelleenkäyttää“ asiakasvalidointeja.
• Mobiilisovellusten tulee toimia offline-tilassa, mutta niiden ei pitäisi duplikoida toiminnallisia sääntöjä.
• Integraatiot tarvitsevat vakaita, versiolle sidottuja sopimuksia ja selkeää virhesemantiikkaa.
• Compliance vaatii jäljitettävät pääsyt, roolimallin ja auditoinnin.

APIstä tulee paikka, jossa liiketoimintalogiikka, käyttöoikeudet ja datan käyttö kohtaavat. Sen arkkitehtuuri ratkaisee sen, pysyykö järjestelmänne pitkällä aikavälillä laajennettavana — vai luoko se vain uusia teknisiä velkoja.

Delphi alustana REST-servereille: vahvuudet ja tyypilliset käyttötapaukset

Delphi yhdistetään usein työpöytäsovelluksiin. REST-serveleille Delphi on kuitenkin myös erittäin sopiva, erityisesti kun kyse on olemassa olevan liiketoimintalogiikan uudelleenkäytöstä tai suorituskykyisistä palveluista. Tyypillisiä käyttötapauksia B2B-ympäristöissä:

• API-kerros kantajärjestelmälle: Olemassa oleva Delphi-toimintasovellus säilyy käyttöliittymänä, ja REST-serveri kapseloi tietokantakutsut ja säännöt uusille kuluttajille.
• Backend portaali- / asiakasalueelle: Web-portaali käyttää REST-endpointteja, jotka käyttävät samaa sääntökärkeä kuin sisäiset prosessit.
• Integraatio- ja rajapintapalvelin: ERP/DMS/CRM-liitännät, tuonti / vienti, event-käsittely, ajastetut työt.
• Linux-palvelut tai Windows-palvelut: pitkään käynnissä olevat prosessit, queue-workerit, schedulerit, dokumenttityönkulut.

Päätöksenteossa vähemmän ratkaisee frameworkin etiketti kuin kuri kerroksistuksessa, rinnakkaisuudessa, virheenkäsittelyssä ja käyttöönotossa. Delphi mahdollistaa molemmat: nopeasti toimitettavat iteroinnit ja samalla puhtaan, modulaarisen arkkitehtuurin — jos suunnittelu tehdään tietoisesti.

Kerrosmalli: Layer-3-arkkitehtuuri perustana pitkäikäisille API:ille

Yritysohjelmistoissa selkeä, kevyt kerrosmalli on osoittautunut toimivaksi. Delphi-ympäristössä tätä kuvataan usein Layer-3-arkkitehtuurina. Termit vaihtelevat, mutta vastuut tulee määritellä selkeästi:

1) API-/Transport-layer (HTTP, serialisointi, routing)

Tämä kerros huolehtii HTTP:stä, protokollatason autentikoinnista, request/response-formaateista, reitityksestä, statuskoodeista, Content-Typesta ja pakkaamisesta. Tähän kerrokseen ei kuulu liiketoimintasääntöjä. Tavoite: vaihdettavuus ja testattavuus. Jos myöhemmin laajennatte REST-APIa muihin protokolliin (esim. WebSocket, gRPC-tyyppiset mallit, Server-Sent Events), liiketoimintaydin säilyy vakaana.

2) Domain-/Service-Layer (liiketoimintalogiikka, use caset, oikeudet, transaktiot)

Täällä asuu toiminnallinen totuus: tila-koneet, laskelmat, plausibiliteetit, tenant-säännöt ja oikeustarkistukset liiketoimintatoimille. Tämän kerroksen tulisi olla riippumaton käyttöliittymästä ja mieluiten ilman HTTP-tuntemusta. Ihanteellista on toteuttaa käytännön tehtäviä kuten „Hyväksy tilaus“, „Sulje tiketti“, „Luo lasku“ sen sijaan, että tarjotaan pelkkää CRUDia taulujen päälle.

3) Data-Access-Layer (repositoryt, SQL, FireDAC, mapping)

Tämä kerros kapseloi persistoinnin: SQL, stored proceduret, transaktioiden hallinta, lukituskonseptit, connection-pooling ja tietokantakohtaiset erityispiirteet. Delphi-ympäristössä BDE-Ablosung mit nativer Anbindung on usein pragmaattinen valinta, erityisesti migraatioissa (BDE-korvauksessa) ja heterogeenisissä tietokantaympäristöissä (SQL Server, PostgreSQL, MariaDB, Firebird). Tärkeää on, että Data-Access-kerros ei tunne HTTP:tä eikä tee liiketoimintapäätöksiä.

Tämä malli vähentää kytkentöjä: muutokset tietomallissa eivät pakota API:n uudelleenkirjoitukseen, ja uudet asiakkaat perivät automaattisesti saman logiikan. Erityisesti Delphi-modernisoinnissa tämä on perusta, jonka avulla kasvanut työpöytäsovellus voidaan irrottaa vaiheittain keskeyttämättä käyttöä.

API-suunnittelu yritysohjelmistoille: ei pelkkää CRUDia, vaan toiminnallisia sopimuksia

Monet API:t alkavat endpointeilla kuten /customers, /orders, /documents ja toteuttavat CRUDin. Se voi riittää sisäisiin työkaluihin, mutta yritysohjelmistoissa se jää nopeasti pinnalliseksi. Liiketoimintaprosessit koostuvat tilamuutoksista, säännöistä, sivuvaikutuksista ja käyttöoikeuksista.

Resurssit, toiminnot ja tilat selkeästi mallinnettuina

Parempi malli yhdistää resurssit ja selkeät toiminnot, esimerkiksi:

• Resurssin lukeminen: GET /orders/{id}
• Toiminnon käynnistäminen: POST /orders/{id}/release
• Dokumentin luominen: POST /orders/{id}/documents/invoice
• Tilanne tarkistus: GET /orders/{id}/status

Tällä API-sopimuksessa tehdään näkyväksi, että „Vapauttaminen“ ei ole pelkkä kentän päivitys. Palvelin voi keskitetysti toteuttaa validoinnit, oikeudet, transaktiot, auditoinnin ja sivuprosessit.

Virhesemantiikka ja validointi: tee virheistä asiakkaalle suunniteltavissa

Yrityskäyttöiset asiakkaat tarvitsevat kyvyn erottaa virhetyypit: validointivirheet (400), puuttuva oikeutus (403), ristiriita rinnakkaismuutoksesta (409), toiminnallinen hylkäys (usein myös 409 tai 422), väliaikaiset backend-ongelmat (503). Tärkeää on yhtenäinen virherakenne, esimerkiksi virhekoodi, viesti, valinnaiset kenttäviitteet ja korrelaatio-ID. Näin portaali voi näyttää ymmärrettäviä ohjeita ja samalla tuki ja käyttö tehokkaasti jäljittää tapahtumia.

Tietoturva: todentaminen ei ole sama kuin valtuutus

B2B-konteksteissa tietoturvan kompastuskivi ei yleensä ole salaus vaan identiteetin, roolien ja toiminnallisten oikeuksien erottelu. REST-serveriarkkitehtuurin tulee siksi erottaa kaksi tasoa:

Authentifizierung (kuka se on?)

Yleisiä menetelmiä ovat token-pohjaiset lähestymistavat (esim. JWT tai opaque-tokenit), yhdistettynä TLS:ään ja selkeään istuntostrategiaan. Ratkaisevaa on tokenin elinikä, refresh-mekanismi, lukitus roolimuutosten yhteydessä sekä se, onko portealeille ja sisäisille järjestelmille eri identiteetin tarjoajia. Delphi-serverit voivat toimia resource-servereina tai – riippuen asetuksesta – myös tokenien myöntäjinä. Monissa yritysmaisemissa integraatio olemassa oleviin identiteettijärjestelmiin (esim. AD/LDAP, SSO-ratkaisut) on keskeinen osa.

Autorisierung (saako hän tehdä sen?)

Valtuutus kuuluu Domain-/Service-layeriin. Roolit ja oikeudet harvoin ovat pelkästään teknisiä; ne liittyvät tenanttiin, sijaintiin, organisaatioyksikköön, sopimustilaan tai prosessivaiheeseen. Hyviä käytäntöjä ovat:

• Roolimalli (esim. Admin, Sachbearbeitung, Auditor) pohjana
• Toiminnalliset käytännöt („voi luoda laskun vain tilassa X“, „voi nähdä vain omat tiketit“)
• Monivuokraisuus oletuksena: jokainen pyyntö tarvitsee vuokralaiskontekstin
• Auditointi: kuka käynnisti minkä toiminnon ja milloin

API ei saisi vain palauttaa „pääsy sallittu/hylätty“, vaan estää palvelimella johdonmukaisesti parametrien väärinkäytöstä johtuvat näkymät muiden vuokralaisten dataan. Tämä vaikuttaa itsestäänselvältä, mutta kasautuneissa järjestelmissä se on yksi yleisimmistä arkkitehtuurivirheistä, kun „taulut laitetaan HTTP:n päälle“ liian nopeasti.

Datakäyttö FireDAC:llä — transaktiot, poolaus ja tietokantastrategia

Yrityssovelluksissa datakäyttö on vakauden kulmakivi: kuormahuiput, deadlockit, pitkät raportit, rinnakkaispäivitykset, erätuonnit. FireDAC on Delphi-ekosysteemissä todettu komponentti, joka tarjoaa yhtenäisen pääsyn eri tietokantoihin. REST-serveriarkkitehtuurin kannalta erityisen tärkeää on:

Transaktiorajat per use case

REST-API on tyypillisesti request-pohjainen. Tämä sopii hyvin „transaktio per use case“ -malliin: requestin aikana avataan transaktio, suoritetaan liiketoimintaoperaatiot ja sitten commit/rollback. Tärkeää: älä automaattisesti pakkaa jokaista endpointia transaktioon, mutta ole johdonmukainen kirjoittavissa toiminnoissa. Lukupäätteet voivat myös tarvita transaktion riippuen isolation-levelista, jos konsistentit näkymät ovat tärkeitä.

Connection-strategia ja rinnakkaisuus

Palvelimen rinnakkaisuus tarkoittaa: paljon samanaikaisia pyyntöjä, jokaisella DB-kutsut. Suunnittele siis:

• rajoitetut, valvotut pool-koot
• time-outit queryille ja yhteyksille
• selkeät säännöt pitkään käynnissä oleville operaatioille (siirrä ne jobeihin/worker-prosesseihin)

Yleinen virhe on ajaa raskaiden raporttien tai massadatavien vienti synkronisesti samalla API-instanssilla, joka palvelee interaktiivisia portaali- tai käyttöliittymäpyyntöjä. Parempi on erottaa interaktiivinen ja batch/async-liikenne.

Tietokantamodernisointi osana API-suunnittelua

Jos olemassa on vielä vanhoja tietokantakutsuja (esim. BDE), API muuttuu katalysaattoriksi: se pakottaa selkeisiin datan käyttörajoihin. Hallittu siirtymä FireDAC:iin pienentää riskejä ja lisää siirrettävyyttä (PostgreSQL, MariaDB, SQL Server). Tärkeää on olla suunnittelematta „isoksi kerralla“, vaan vaiheittain: uudet server-use-caset käyttävät jo uutta Data-Access-kerrosta, kun vanhat osat tulevat perässä.

Versionointi ja taaksepäin yhteensopivuus: API-sopimukset suojaavat

Yritykset aliarvioivat usein, kuinka kallista Breaking Change on. Kun asiakasportaali, kumppanijärjestelmä tai Windows-palvelu perustuu APIinne, ette voi enää „muuttaa kenttänimeä nopeasti“. Selkeä versionointistrategia on siksi pakollinen.

Pragmaattiset säännöt versionoinnille

• Ei breaking changeja ilman versiota: älkää nimekö tai poistako kenttiä, älkää tulkitko endpointteja eri tavalla.
• Laajenna älä muuta: lisää uusia kenttiä, merkitse vanhat deprecatediksi.
• Yhteensopivat oletusarvot: vältä uusia pakollisia kenttiä tai johda ne palvelinpuolella.
• Ekspliciittinen versionointi: esim. /v1/… tai headerin kautta; tärkeämpää kuin tapa on johdonmukaisuus.

Delphi-tiimeille tämä tarkoittaa myös: pidä DTO:t (Data Transfer Objects) vakaina ja suunniteltuina, älä serialisoi domain-objekteja 1:1. Se lisää alkuvaiheen työtä, mutta laskee pitkällä aikavälillä tukikustannuksia.

Havaittavuus: lokitus, metrikkat ja jäljitettävyys suunnitellaan alusta alkaen

Tuotantokäytössä „minulla toimii“ on arvotonta, jos virheitä ei voi toistaa. Erityisesti REST-serverit, jotka palvelevat monia kuluttajia, tarvitsevat vähintään perustason havaittavuutta:

Rakenteinen lokitus ja korrelaatio-ID

Jokaisella pyynnöllä tulisi olla korrelaatio-ID (ottaa vastaan tai generoida) ja sen tulee näkyä lokeissa. Lokimerkinnät tulisi olla strukturoituja (esim. JSON), jotta ne voidaan syöttää keskitettyihin järjestelmiin. Vähintään relevanttia on:

• Request-metodi, reitti, statuskoodi, kesto
• User-/tenant-konteksti (pseudonymisoituna/tietosuojasääntöjen mukaisesti)
• DB-kesto ja virheluokka
• Korrelaatio-ID tukitoimintaa varten

Metrikat kapasiteetille ja virhetrendeille

Skaalautumisen ja vakauden arvioimiseksi tarvitsette metriikat: requestit per minuutti, p95/p99-latenesit, virheprosentit endpointteittain, DB-poolin käyttöaste, jonon pituudet. Tämän ei tarvitse olla „cloud-native overkill“, mutta ilman lukuja suorituskykykeskustelut jäävät mielipidepohjaisiksi.

Virhe- ja poikkeusten käsittely arkkitehtuurikomponenttina

Delphi-poikkeusten ei pidä vuotaa ulos hallitsemattomasti. Keskitetty poikkeusmiddleware (tai globaali handler) muuntaa poikkeukset yhtenäisiksi virhevastausten muodoiksi, sisältäen tukitunnuksen ja järkevän HTTP-koodin. Sisäisesti stacktracet kuuluvat suojattuihin lokiin, eivät asiakasvastauksiin.

Synkroninen vs. asynkroninen: pitkät prosessit pois REST-vastauksesta

Monet yritysprosessit eivät ole „request/response 200 ms“: PDF-generointi, datatuonti, rajapintakierrot, täsmäykset, massamuutokset, arkistointi. Nämä kuormat eivät yleensä kuulu synkroniseen REST-endpointtiin, koska ne sitovat säikeitä, aiheuttavat timeouteja ja estävät käyttäjän.

Job-malli

Toimiva ratkaisu on: endpoint käynnistää työn ja palvelin palauttaa välittömästi job-ID:n. Toinen endpoint tarjoaa statuksen/tuloksen. Valinnaisesti callback/webhook voi ilmoittaa valmiudesta. Delphi-ympäristössä tämä toteutetaan worker-palveluilla, job-taululla ja selkeällä tilakoneella. Etu: vakaus ja ennustettava skaalautuminen.

Jonot ja palvelut

Tarpeesta riippuen viestijono voi olla hyödyllinen, mutta se ei ole aina pakollinen. Tärkeintä on periaate: interaktiiviset APIt pysyvät responsiivisina, batch-prosessit ajetaan kontrolloidusti, toistettavasti ja havaittavasti — joko Windows- tai Linux-palveluina riippuen deploy-strategiasta.

Deploy yrityksessä: Windows, Linux, kontit, On-Prem

REST-serveriarkkitehtuuri on valmis vasta kun se on operoitavissa. Yritykset eroavat merkittävästi: perinteiset Windows-palvelimet, virtualisoidut Linux-isännät, konttialustat, tiukat verkkoalueet, proxy- ja sertifikaattivaatimukset. Delphi on tässä joustava, kun riippuvuudet hallitaan siististi.

Konfiguraatio ja salaisuudet

Konfiguraation tulee olla ympäristöriippuva (Dev/Test/Prod). Käyttäjätunnukset ja salaisuudet eivät kuulu EXE:iin tai lähdekoodivarastoon. Käytä turvallista säilytystä (esim. alustan secrets-management) ja erottele konfiguraatio koodista. Suunnittele myös kierrätykset (DB-salasanat, API-avaimet) ilman, että järjestelmää tarvitsee rakentaa uudelleen.

Release- ja rollback-strategiat

Kun useita kuluttajia on kytketty APIin, tarvitsette kontrolloidut julkaisuprosessit: migration-skriptit tietokantamuutoksille, feature-togglet vaiheittaiseen aktivointiin ja selkeät rollback-polut. Erityisesti tietokantamuutosten tulee olla taaksepäin yhteensopivia, jos server-version rollback halutaan mahdollistaa.

Integrointi olemassa olevaan ohjelmistoon: asteittainen modernisointi Big Bangin sijaan

Monissa Delphi-ympäristöissä liiketoimintasydän on arvokas mutta teknisesti „liimautunut“: UI-läheiset tietokantakutsut, globaalit tilat, sekaantuneet vastuut. REST-API voi olla sekä riski että mahdollisuus. Tavoitteena tulisi olla polku, joka tuottaa mitattavaa hyötyä kohtuullisella työllä.

Strangler-ansatz API:ille

Sen sijaan, että kaikki rakennetaan kokonaan uudestaan, määrittäkää toiminnalliset rajapinnat, jotka tuottavat todellista hyötyä: esim. „tilauksen status ja dokumentit asiakasportaalille“, „rekisteritiedon haku mobiilikäyttäjille“, „rajapinta ERP-kirjauksille“. Nämä use caset toteutetaan uusina API-toiminnoina, mukaan lukien domain-layer ja data-access. Vanha asiakas voi vaiheittain siirtyä käyttämään samoja server-use-caseja ilman, että käyttöliittymää tarvitsee heti uudistaa.

Yhteinen liiketoimintalogiikka: järkevää, mutta hallitusti

Delphi mahdollistaa liiketoimintakirjastojen käytön sekä serverissä että olemassa olevissa sovelluksissa. Se voi toimia siltana mutta sisältää myös vaaroja: jos UI-riippuvuudet vuotavat yhteiseen logiikkaan, irrotus katoaa. Selkeä sääntö auttaa: yhteiskäyttöön kelpaa vain logiikka ilman UI-riippuvuuksia, ilman globaaleja tiloja, selkeillä rajapinnoilla ja testattavilla yksiköillä. Kaikki muu pidetään erillään.

Tyypilliset virheet REST-server-projekteissa — ja miten välttää ne

„Wir veröffentlichen einfach Tabellen“

Kun endpointit peilaavat suoraan tauluja, syntyy epävakaa järjestelmä: jokainen DB-refaktorointi on API-breaking-change, liiketoimintasäännöt duplikoituvat asiakkaissa ja parametrien tarkistamattomuus avaa tietoturvariskejä. Parempi on: domain-use-caset ja DTO:t, jotka vakauttavat sopimusta.

Liiketoimintaoikeudet vain clientissa

Clientit ovat vaihdettavia ja manipuloitavissa. Valtuutus kuuluu serveriin ja sen on huomioitava toiminnalliset säännöt, ei pelkät tekniset roolit.

Ei selvää strategiaa rinnakkaisuudelle

Rinnakkaisia päivityksiä tapahtuu: kaksi käsittelijää, portaali ja sisäinen client tai import-jobi. Ilman optimistic lockingia (esim. RowVersion/Timestamp), konfliktikoodeja (409) ja selkeitä merge-sääntöjä syntyy datan menetystä tai „viimeinen kirjoittaa voittaa“ -ongelmia.

Pitkät prosessit blokkaavat interaktiiviset endpointit

Synkroninen PDF-tuotanto tai vienti aiheuttaa timeouteja ja „jumiutuu“-kokemuksia. Parempi on job-malli ja status-endpointit.

Havaittavuus kiinnitetään jälkikäteen

Ilman korrelaatio-ID:tä, strukturoituja lokeja ja metriikoita jokainen häiriö muuttuu etsinnäksi. Havainnollisuus ei ole ylellisyys vaan käyttöönoton vaatimus.

Konkreettinen tarkistuslista REST-server-arkkitehtuurille Delphi:lla

• Erottele kerrokset selkeästi: Transport (HTTP), Domain (Use Cases), Data Access (FireDAC/SQL).
• Ymmärrä API sopimuksena: pidä DTO:t vakaina, suunnittele versionointi, vältä breaking changeja.
• Tietoturva kahdella tasolla: Authentifizierung (token) plus Autorisierung (toiminnalliset politiikat, tenant).
• Aseta transaktiot tietoisesti: per use case, time-outit, konfliktistrategia.
• Pitkät prosessit asynkronisiksi: Jobs/Workerit, Windows- tai Linux-palvelut.
• Rakenna havaittavuus: korrelaatio-ID, strukturoitu lokitus, metriikat, keskitetty virheenkäsittely.
• Suunnittele deploy realistisesti: konfiguraatio/salaisuudet, rollback, tietokantamigraatiot.
• Modernisoi iteratiivisesti: hyödylliset use caset ensin, vanhat osat irrotetaan vaiheittain.

Yhteenveto: REST-serverit tuovat arvoa vasta osana käyttö- ja toiminnallista arkkitehtuuria

REST-serveriarkkitehtuuri Delphi:lla on yrityksille erityisen tehokas, kun sitä ei lähestytä pelkkänä „teknisenä pinnana“, vaan yhdistävänä ytimenä prosessien, datan ja kanavien välillä. Ratkaisevaa ovat puhtaat kerrokset (Layer-3-arkkitehtuuri), toiminnallisesti mallitetut endpointit, johdonmukainen turvallisuus- ja tenant-logiikka sekä käyttömalli, jossa on versionhallinta, monitorointi ja hallittu rinnakkaisuus. Näin APIstä syntyy vakaa alusta portaaleille, integraatioille, palveluille ja vaiheittaiselle Delphi-modernisoinnille — ilman että kasvanneen järjestelmän toiminnallinen sisältö vaarantuu.

Jos haluatte arvioida, miten kestävä REST-API voidaan perustaa olemassa olevaan Delphi-maisemaan (mukaan lukien tietokantastrategia, FireDAC, palvelut ja käyttö), tavoitatte meidät täällä: https://net-base-software-gmbh.de/kontakt/