REST-Serveris un pakalpojumi

Daudzām uzņēmumu lietojumprogrammām šodien ir vajadzīgs vairāk nekā viens klients. Pie tā pieder saskarnes, portāli, laika plānošana, integrācijas, fona apstrāde un tehniskā ekspluatācijas loģika. Tieši tāpēc mēs REST serverus un servisus neplānojam kā vēlāk piebūvētu papildinājumu, bet kā daļu no tās pašas arhitektūras.

Kad pakalpojumu orientēts sadalījums ir jēgpilns

• ja vairākiem klientiem ir jāpieiet pie vienas un tās pašas domēna loģikas
• ja fona procesiem vairs nevajadzētu būt piesaistītiem atsevišķām darba vietām
• ja portāli, darbvirsma un trešo pušu sistēmas kontrolēti izmanto vienu un to pašu datu bāzi
• ja laidieni, ekspluatācija un tehniskā atbildība ir jāspēj mērogot

REST serveri un pakalpojumi kā daļa no tās pašas domēna loģikas

Daudzos uzņēmumos API un fona pakalpojumi rodas pārāk vēlu un spiediena apstākļos. Tad esošais darbvirsmas risinājums tiek pēc tam paplašināts ar saskarnēm, kamēr biznesa noteikumi joprojām paliek paslēpti klientā. Tas gandrīz neizbēgami noved pie nekonsekvencēm: viens un tas pats noteikums pastāv vairākas reizes, kļūdu ainas kļūst grūtāk izsekojamas un ekspluatācija balstās uz īpašām zināšanām.

Mēs ejam pretēju ceļu. Ja sistēmai ir vajadzīgi portāli, integrācijas, importi, eksports, licenču pārbaudes vai fona apstrāde, atbildība starp klientu, REST serveri un pakalpojumu ir jānoskaidro agrīni. Kura loģika ir domēniski centrāla? Kuras darbības ir jāspēj reproducēt? Kā tiek protokolētas kļūdu situācijas? Kā vēlāk var paplašināt datu plūsmas, neatgriežoties pie atkarības no monolīta?

Tieši Delphi sistēmās šis punkts ir svarīgs. Daudz vērtīgas biznesa loģikas bieži jau atrodas esošajā risinājumā. Tam, kurš no tās atvasina REST serveri vai Linux- un Windows servisus, nevajadzētu vienkārši kopēt pirmkodu, bet gan korekti atdalīt kopīgo domēna pamatu no lietojumprogrammas. Tikai tad rodas API un pakalpojumi, kas runā tajā pašā valodā kā klients.

Kam uzņēmumiem vajadzētu pievērst uzmanību REST un servisos

Svarīgākā kļūda parasti nav tehniska, bet strukturāla: projekts domā, ka ar API arhitektūras jautājums jau ir atrisināts. Patiesībā tas tur tikai sākas. API, portāliem, darbvirsmas klientiem un servisiem ir jāsaprot viena un tā pati datu bāze, tās pašas lomas un tie paši biznesa noteikumi.

Ja šī līnija ir skaidra, paplašinājumus var plānot daudz drošāk. Portāls var piekļūt tai pašai servera loģikai, fona servisi var kontrolēti apstrādāt tos pašus objektus, un trešo pušu integrācijas paliek piesaistītas skaidri definētā biznesa vietā. Tieši no šīs perspektīvas mēs daudzplatformu klientus, servera loģiku un datu glabāšanu skatām kā savstarpēji saistītu sistēmu, nevis kā vaļīgus atsevišķus blokus.

Beigās laba REST un servisu arhitektūra nav atpazīstama pēc tā, cik moderni tā skan, bet pēc tā, cik mierīgi to vēlāk var ekspluatēt. Ja atbalsta gadījumi paliek izsekojami, kļūdu ceļi ir redzami un jaunas prasības vairs nebeidzas ar apkārtceļiem vecajā kodā, ir sasniegts patiesais tehniskais ieguvums.

Pēc kā var atpazīt, ka REST un servisi arhitektoniski ir jāizstrādā tīri un savlaicīgi

Tiklīdz vairākiem klientiem, integrācijām vai fona procesiem ir vajadzīgi vieni un tie paši noteikumi, no API idejas kļūst sistēmas jautājums. Tieši tur izšķiras, vai vēlāk būs miers vai pastāvīga berze.

Ko vajadzētu sniegt pirmajai arhitektūras izpētei REST un servisiem

Lielākais sviras efekts bieži slēpjas nevis framework, bet tīrā atbildību sadalījumā starp klientu, serveri un fona procesiem.

• ietvaru, kura loģika biznesa ziņā jāatstāj centrā un kam jānonāk servisos
• skatījumu uz lomām, datu ceļiem, žurnālošanu un tehniskajiem ekspluatācijas stāvokļiem
• sākuma ceļu API, fona darbiem un integrācijām bez nekontrolētas paralēlās pasaules

BUJ par REST-serveriem un servisiem

Daudzas sistēmas neizgāžas API idejas dēļ, bet gan tāpēc, ka servera loģika vēlāk tiek improvizēti piekabināta esošai Desktop bāzei. Mēs šīs daļas apzināti plānojam kopā.