REST-Serveris un pakalpojumi

Daudzām uzņēmumu lietojumprogrammām šodien vajag vairāk nekā vienu klientu. Tam pieder saskarnes, portāli, laika vadība, 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 pievienotu pielikumu, bet kā tās pašas arhitektūras daļu.

Kad ir jēgpilns servisorientedts griezums

• ja vairākiem klientiem ir jāpiekļūst tai pašai nozares loģikai
• ja fona procesiem vairs nav jābūt piesaistītiem atsevišķām darba vietām
• ja portāli, darbvirsma un trešo pušu sistēmas kontrolēti izmanto to pašu datu bāzi
• ja relīzes, ekspluatācija un tehniskā atbildība ir jāsaglabā mērogojama

REST serveri un pakalpojumi kā tās pašas nozares loģikas daļa

Daudzos uzņēmumos API un fona pakalpojumi rodas pārāk vēlu un spiediena apstākļos. Tad esoša darbvirsmas sistēma tiek pēc tam paplašināta ar saskarnēm, kamēr biznesa noteikumi turpina būt paslēpti klientā. Tas gandrīz neizbēgami noved pie nekonsekvencēm: viens un tas pats noteikums eksistē 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ējo ceļu. Ja sistēmai vajag portālus, integrācijas, importus, eksportu, licenču pārbaudes vai fona apstrādi, atbildība starp klientu, REST serveri un servisu ir jānoskaidro agrīni. Kura loģika ir nozares ziņā centrāla? Kurām darbībām jābūt reproducējamām? 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ā. Tas, kurš no tā atvasina REST serveri vai Linux- un Windows-servisus, nedrīkst vienkārši kopēt pirmkodu, bet gan tīri atdalīt kopīgo nozares pamatu no lietojumprogrammas. Tikai tad rodas API un servisi, kas runā tajā pašā valodā kā klients.

Kam uzņēmumiem būtu jāpievērš uzmanība, strādājot ar REST un pakalpojumiem

Svarīgākā kļūda parasti nav tehniska, bet strukturāla: projekts uzskata, ka ar API arhitektūras jautājums jau ir atrisināts. Patiesībā tas tikai tur sākas. API, portāliem, desktop klientiem un pakalpojumiem 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 nostiprināta, paplašinājumus var plānot daudz drošāk. Portāls var piekļūt tai pašai servera loģikai, fona pakalpojumi var kontrolēti apstrādāt tos pašus objektus, un trešo pušu integrācijas paliek pieslēgtas vienā biznesa ziņā skaidri definētā vietā. Tieši no šīs perspektīvas mēs multiplatformu klientus, servera loģiku un datu glabāšanu skatām kā vienotu sistēmu, nevis kā vaļīgus atsevišķus būvblokus.

Beigās laba REST un pakalpojumu arhitektūra nav atpazīstama pēc tā, cik moderni tā skan, bet gan 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 vecā kodā, ir sasniegts patiesais tehniskais ieguvums.

Pēc kā var saprast, ka REST un pakalpojumi arhitektūras ziņā ir rūpīgi jāsagatavo

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

Ko būtu jāsniedz pirmajai arhitektūras uzskaitei par REST un pakalpojumiem

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

• klasifikāciju par to, kurai loģikai biznesa ziņā jāpaliek centrālai un kam jānonāk pakalpojumos
• skatījumu uz lomām, datu ceļiem, žurnālošanu un tehniskajiem ekspluatācijas stāvokļiem
• starta ceļu API, fona darbu un integrāciju izveidei bez nekontrolētas paralēlās pasaules

BUJ par REST serveriem un pakalpojumiem

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 darbvirsmas sistēmai. Mēs šīs daļas apzināti plānojam kopā.