API profils
Delphi REST-API un REST-Servera pārskats
REST ar Delphi ir ekonomiski spēcīgs tad, ja esošā biznesa loģika netiek izmesta, bet sakārtoti iznesta uz āru. Tā vietā, lai līdzās esošajam veidotu paralēlu tīmekļa pasauli, mēs izstrādājam REST serverus tā, lai noteikumi, dati un procesu loģika kontrolēti paliktu kopā.
REST galapunkti ar nozares atbildību
Laba API neatspoguļo tikai datus, bet arī lomas, apstiprinājumus, validācijas un stāvokļu maiņas, kas uzņēmumā patiešām ir būtiskas.
Delphi-REST serveris kā esošās sistēmas daļa
Ja nozares loģika jau ir izaugusi Delphi, tīrs REST serveris var šo substanci produktīvi nest tālāk, nevis izgudrot no jauna.
Ieplānot logging, monitoring un kļūdu ceļus
API ir jāstrādā mierīgi, tai jābūt novērojamai un konsekventi jāsaspēlējas ar klientiem, portāliem un servisiem. Tieši to mēs ieplānojam jau no paša sākuma.
Kad REST serveris ar Delphi kļūst īpaši lietderīgs
Tiklīdz vairākiem klientiem, tīmekļa piekļuves punktiem, mobilajiem scenārijiem, integrācijām vai fona dienestiem jāizmanto viena un tā pati nozares loģika, tieša piekļuve datubāzei bieži kļūst par šauru vietu. Tad REST serveris ir punkts, kur noteikumi, dati un kontrole jēgpilni saplūst kopā.
Īpaši izaugušās Delphi sistēmās tā ir liela priekšrocība. Tā vietā, lai jaunas prasības izspiestu cauri UI-tuvam mantotam kodam, biznesa loģiku var pakāpeniski pārnest uz serverim piemērotu centru. Tā rodas REST galapunkti, kas ir ne tikai tehniski sasniedzami, bet arī nozares ziņā uzticami. Tieši tādēļ Delphi klients, portāls un integrācijas paliek konsekventas, nevis jāuztur vairākas vienu un to pašu noteikumu versijas.
Patiesais ieguvums parādās vēlāk ekspluatācijā. Tīri nošķelts REST serveris vienkāršo tiesību un apstiprinājumu loģiku, stabilizē ārējos pieslēgumus, atslogo bīstamus tiešos piekļuves ceļus uz datubāzi un rada labāku pamatu Windows- un Linux-servisiem vai klientu portāliem. Tāpēc mēs REST neuzskatām par protokola jautājumu, bet gan par arhitektūras soli.
- Nozares loģiku neieslēgt formās, bet strukturēt serverim piemērotā veidā
- Veidot REST galapunktus ar lomām, validācijām un tīru datu modeli
- Logging, monitoring un kļūdu apstrādi ieplānot produktīvai videi tuvu
- Sasaistīt klientus, portālus un servisus caur vienu un to pašu nozares centru
Kas REST arhitektūrās ar Delphi bieži tiek palaists garām
Daudzi REST projekti izgāžas nevis uz ietvara, bet tāpēc, ka nozares atbildība paliek mantotajā sistēmā un API kļūst tikai par plānu transporta slāni. Tad sākas dublēšanās, nekonsekvences un operatīvi apkārtceļi.
Mēs tieši to novēršam, vispirms noskaidrojot, kuri noteikumi jācentralizē, kuri datu ceļi jau ir kritiski un kur vēlāk jāpieslēdzas portāliem vai integrācijām. No tā izriet REST griezums, kas darbojas gan pašreizējam esošajam stāvoklim, gan nākotnes paplašināšanas ceļiem. Daudzos gadījumos tas tieši ved tālāk uz servisiem un portāliem vai uz pārklājošu Layer-3 arhitektūru.
API nevis paralēlā pasaule
REST serveris kļūst ekonomiski pamatots, ja tas nes to pašu biznesa saturu kā esošais risinājums un nevis tikai pievieno jaunus galapunktus līdzās vecajiem noteikumiem.
Tiesības un stāvokļi paliek centrāli
Lomu modelim, validācijām un statusa pārejām nav jāatrodas atsevišķos klientos, bet gan kopīgā biznesa kodolā.
Ekspluatācija kļūst plānojama
Ja logi, tehniskie kļūdu ceļi un fona procesi tiek pārdomāti savlaicīgi, no API neizveidojas vēlākas atbalsta lamatas.