API-profiili
Delphi REST-API ja REST-Server yleiskatsaus
REST yhdessä Delphi:n kanssa on taloudellisesti vahva silloin, kun olemassa olevaa business-logiikkaa ei heitetä pois, vaan se tuodaan hallitusti ulospäin. Sen sijaan, että rakennettaisiin rinnakkainen web-maailma nykyisen järjestelmän viereen, toteutamme REST-palvelimet niin, että säännöt, data ja prosessilogiikka pysyvät hallitusti yhdessä.
REST-päätepisteet liiketoimintavastuulla
Hyvä API ei mallinna vain dataa, vaan myös roolit, hyväksynnät, validoinnit ja tilasiirtymät, jotka ovat yrityksessä oikeasti relevantteja.
Delphi-REST-palvelin osana nykyjärjestelmää
Kun liiketoimintalogiikka on jo kasvanut ja vakiintunut Delphi:ssä, siisti REST-palvelin voi kantaa tämän substanssin tuotantoon, sen sijaan että se keksittäisiin uudelleen.
Lokitus, monitorointi ja virhepolut mukaan suunnitteluun
API:en on toimittava vakaasti, oltava havainnoitavia ja pelattava yhteen asiakkaiden, portaaleiden ja palveluiden kanssa johdonmukaisesti. Juuri tämän suunnittelemme mukaan alusta alkaen.
Milloin REST-palvelin yhdessä Delphi:n kanssa on erityisen järkevä
Heti kun useiden asiakkaiden, web-yhteyksien, mobiiliskenaarioiden, integraatioiden tai taustapalveluiden on tarkoitus hyödyntää samaa liiketoimintalogiikkaa, suora tietokantayhteys käy usein liian ahtaaksi. Silloin REST-palvelin on se kohta, jossa säännöt, data ja kontrolli kootaan järkevästi yhteen.
Erityisesti kasvaneissa Delphi-järjestelmissä tämä on suuri etu. Sen sijaan että uusia vaatimuksia runnottaisiin UI-läheistä legacy-koodia vasten, business-logiikka voidaan vaiheittain siirtää palvelinkelpoiseen keskukseen. Näin syntyy REST-päätepisteitä, jotka eivät ole vain teknisesti saavutettavia, vaan myös liiketoiminnallisesti kestäviä. Juuri tämän ansiosta Delphi-asiakas, portaali ja integraatiot pysyvät johdonmukaisina sen sijaan, että ylläpidettäisiin useita versioita samoista säännöistä.
Varsinainen hyöty näkyy myöhemmin käytössä. Selkeästi rajattu REST-palvelin yksinkertaistaa oikeus- ja hyväksyntälogiikkaa, vakauttaa ulkoiset liitännät, keventää kohtalokkaita suoria tietokantakäyttöjä ja luo paremman perustan Windows- ja Linux-Services -ratkaisuille tai asiakasportaaleille. Siksi emme käsittele REST:ää protokollakysymyksenä, vaan arkkitehtuurisena askeleena.
- Älä lukitse liiketoimintalogiikkaa lomakkeisiin, vaan rakenna se palvelinkelpoiseksi
- Rakenna REST-päätepisteet rooleilla, validoinneilla ja siistillä datamallilla
- Ota lokitus, monitorointi ja virheenkäsittely tuotantoläheisesti mukaan
- Kytke asiakkaat, portaalit ja palvelut saman liiketoiminnallisen keskuksen kautta
Mitä REST-arkkitehtuureissa yhdessä Delphi:n kanssa usein jää huomaamatta
Monet REST-projektit eivät kaadu frameworkiin, vaan siihen, että liiketoiminnallinen vastuu jää legacy-järjestelmään ja API:sta tulee vain ohut kuljetuskerros. Silloin alkavat päällekkäisyydet, epäjohdonmukaisuudet ja operatiiviset erityisreitit.
Vältämme tämän nimenomaan siten, että selvitämme ensin, mitkä säännöt on oltava keskitettyjä, mitkä datapolut ovat jo kriittisiä ja mihin portaalien tai integraatioiden on tarkoitus myöhemmin kytkeytyä. Tämän perusteella muodostuu REST-rajauksen malli, joka toimii sekä nykyisessä kokonaisuudessa että tulevissa laajennuspoluissa. Monissa tapauksissa tämä johtaa suoraan eteenpäin Services ja portaalit -ratkaisuihin tai kokonaisvaltaiseen Layer-3-arkkitehtuuriin.
API eikä rinnakkaismaailma
REST-palvelin on taloudellisesti perusteltu, kun se kantaa samaa toiminnallista ydintä kuin nykyinen kokonaisuus eikä vain aseta uusia päätepisteitä vanhojen sääntöjen viereen.
Oikeudet ja tilat pysyvät keskitettyinä
Roolimalli, validoinnit ja tilasiirtymät eivät kuulu yksittäisiin client-sovelluksiin, vaan yhteiseen toiminnalliseen ytimeen.
Käyttö tuotannossa muuttuu ennakoitavaksi
Kun lokit, tekniset virhepolut ja taustaprosessit huomioidaan varhain, API:sta ei synny myöhemmin tukiansoja.
REST yhdessä Delphi:n kanssa voi olla erittäin vahva
Edellyttäen, että palvelin ajatellaan saman sovelluksen toiminnalliseksi laajennukseksi eikä irralliseksi web-kerrokseksi nykyisen rinnalle.
REST-palvelin siltana seuraavaan kehitysvaiheeseen
Monet yritykset eivät halua täydellistä korvaamista, vaan polun, joka mahdollistaa portaalin, integraatiot ja modernit käyttötavat ilman, että olemassa olevaa substanssia aliarvostetaan. Juuri tässä siisti REST-arkkitehtuuri näyttää vahvuutensa.
Jos haluatte nähdä, miten Delphi-sovelluksenne voi avautua hallitusti kohti API:a, palveluita ja portaaleja, tämä on usein järkevin lähtökohta. Sieltä käy nopeasti ilmi, viekö seuraava askel kohti palveluja, monialustaisuutta vai tiedonsaantia.
Leikkaa API ensin toiminnallisesti
Kun roolit, validoinnit ja tietomalli ovat selkeästi ohjaavia, REST:stä ei tule rinnakkaisprojektia, vaan sovelluksenne kantava laajennus.
Mistä yritykset tunnistavat, että REST yhdessä Delphi:n kanssa voi olla toiminnallisesti erittäin järkevä
Kun arvokas liiketoimintalogiikka elää jo Delphi-nykytilassa, hyvin rajattu REST-palvelin on usein taloudellisempi kuin toiminnallisesti kaksinkertainen uudelleenimplementointi.
Nykyiset säännöt voidaan siirtää API:ksi
Arvokkaan logiikan ei tarvitse kadota, kun se irrotetaan siististi UI-läheisestä koodista ja rajataan palvelinkelpoiseksi.
Client ja API pysyvät samalla toiminnallisella linjalla
Juuri tämä estää myöhemmät ristiriidat työpöydän, portaalin ja integraatiopolkujen välillä.
Lokitus, oikeudet ja virhepolut keskitetään
Siisti API tuo enemmän jäljitettävyyttä kuin suora tietokantakäyttö monesta suunnasta.
Mitä ensimmäisen REST-palvelinrajauksen Delphi:lle tulisi tuottaa
Onnistuminen riippuu ratkaisevasti siitä, mikä logiikka keskitetään ja miten oikeudet, tietomalli ja käyttö tuotannossa voidaan rajata järkevästi.
- näkemys siitä, mitkä säännöt kannattaa tehdä API-kelpoisiksi ja mikä saa jäädä paikalliseksi
- tulkinta autentikoinnista, lokituksesta, virhepoluista ja käyttöönotosta
- aloituspolku, joka ei päästä työpöytää, API:a ja myöhempiä portaaleja ajautumaan toiminnallisesti erilleen
Suunnittele REST yhdessä Delphi:n kanssa toiminnallisen logiikan pohjalta
Kun API-rajapintoja tarvitaan, tekninen suunta kannattaa johtaa ydinsysteemistä eikä rakentaa sen rinnalle erillistä rinnakkaismaailmaa.
FAQ: Delphi REST-API:t ja REST-Serverit
REST yhdessä Delphi:n kanssa on vahva, kun API:t eivät ole irrallisena kerroksena olemassa olevan rinnalla, vaan kantavat siististi mukana oikeudet, business-logiikan, tietomallin ja käytön.
Voiko Delphi:lla rakentaa tuotantokäyttöön REST-API:t?
Kyllä. Erityisesti silloin, kun sama toiminnallinen logiikka elää jo Delphi-järjestelmässä, siististi rajattu REST-Server on usein taloudellisempi kuin täysin uusi rinnakkaismaailma.
Milloin REST-Server kannattaa suoran tietokantayhteyden sijaan?
Heti kun useiden clientien, portaalien, palveluiden tai integraatioiden pitää käyttää hallitusti samoja sääntöjä ja suora SQL-yhteys muuttuu toiminnallisesti liian riskialttiiksi.
Miten pidätte Delphi-clientin ja REST:n yhdenmukaisina?
Arkkitehtuurilla, jossa business-säännöt eivät jää piiloon lomakkeisiin, vaan ovat yhteiskäytettävissä clientille, API:lle ja taustaprosesseille.
Lue lisää kysymyksiä koottuna
Nämä lyhyet vastaukset pysyvät tällä sivulla. Keskitetyllä FAQ-landingpagella jäsennämme aiheen lisäksi arkkitehtuurin, modernisoinnin, alustojen ja käytön yhteydessä.