REST serveri un pakalpojumi

Mūsdienās daudzām uzņēmumu lietojumprogrammām nepieciešams vairāk nekā viens klients. Saskarnes, portāli, laika vadība, integrācijas, fona apstrāde un tehniskā darbības loģika tam pieder. Tieši tāpēc mēs REST-serverus un pakalpojumus neplānojam kā vēlāk pievienotu papildinājumu, bet kā tās pašas arhitektūras daļu.

Kad servisu-orientēts sadalījums ir jēgpilns

• ja vairākiem klientiem jāpieejo vienai un tai pašai biznesa loģikai
• ja fona procesiem vairs nedrīkst būt piesaiste pie atsevišķām darba vietām
• ja portāli, darbvirsma un trešās puses sistēmas kontrolēti izmanto vienu un to pašu datu bāzi
• ja izlaidumu pārvaldība, ekspluatācija un tehniskā atbildība jāspēj mērogot

REST-Server und Dienste als Teil derselben Fachlogik

Daudzos uzņēmumos API un fona dienesti tiek izstrādāti pārāk vēlu un zem spiediena. Tad esošais darbvirsmas sastāvs pēc tam tiek papildināts ar saskarnēm, kamēr biznesa noteikumi turpina būt paslēpti klientā. Tas gandrīz neizbēgami noved pie nekonsekvencēm: viena un tā pati noteikuma versija parādās vairākas reizes, kļūdu stāvokļu izsekošana kļūst grūtāka un ekspluatācija balstās uz speciālām zināšanām.

Mēs rīkojamies pretēji. Ja sistēmai nepieciešami portāli, integrācijas, importi, eksporti, licences pārbaudes vai fona apstrāde, atbildība starp klientu, REST-serveri un pakalpojumu ir jānosaka laikus. Kādai loģikai ir centrāla nozīme? Kuras darbības jāspēj reproducēt? Kā tiek protokolētas kļūdu situācijas? Kā vēlāk paplašināt datu plūsmas, nepārvēršoties atkal par monolītu?

Īpaši Delphi-sistēmām šis jautājums ir svarīgs. Liela daļa vērtīgas biznesa loģikas bieži jau atrodas esošajā kodā. Kurš no tā atvasina REST-serverus vai Linux- un Windows-pakalpojumus, tam nevajadzētu vienkārši kopēt avota kodu, bet rūpīgi izdalīt kopīgo biznesa bāzi no lietojumprogrammas. Tikai tad rodas API un pakalpojumi, kas runā to pašu valodu kā klients.

Kam uzņēmumiem jāpievērš uzmanība saistībā ar REST un dienestiem

Visbūtiskā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āli, darbvirsmas klienti un dienesti ir jābūvē uz vienas datu bāzes, vienām lomām un vieniem funkcionālajiem noteikumiem.

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, fonā darbojošies dienesti var kontrolēti apstrādāt tos pašus objektus, un trešo pušu integrācijas paliek piesaistītas skaidri definētā funkcionālā vietā. Tieši no šīs perspektīvas mēs uztveram daudzplatformu klientus, servera loģiku un datu uzturēšanu kā vienotu sistēmu, nevis kā vaļīgus atsevišķus moduļus.

Beigu beigās laba REST- un servisu arhitektūra nav atpazīstama pēc tā, cik moderna tā šķiet, bet pēc tā, cik mierīgi to vēlāk var ekspluatēt. Ja atbalsta gadījumi ir izsekojami, kļūdu ceļi redzami un jaunas prasības vairs nebeidzas ar speciālajiem ceļiem vecajā kodā, tad ir sasniegts īstais tehniskais ieguvums.

Kā noteikt, ka REST un dienestiem nepieciešama arhitektoniski rūpīga sagatavošana

Tiklīdz vairāki klienti, integrācijas vai fonā processi prasa tās pašas noteikšanas, 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 pirmā arhitektūras uzņemšana par REST un dienestiem būtu jāsniedz

Lielākais sviras punkts bieži vien nav framework, bet gan tīra atbildības sadale starp klientu, serveri un fonā procesiem.

• izvērtējumu par to, kura loģika funkcionāli jāatstāj centrā un kas jāievieto dienestos
• pārskats par lomām, datu plūsmām, žurnālu reģistrāciju un tehniskajiem ekspluatācijas stāvokļiem
• sākuma ceļš API, fona darbiem un integrācijām bez nekontrolētas paralēlas vides

FAQ zu REST-Servern und Services

Viele Systeme scheitern nicht an der API-Idee, sondern daran, dass Serverlogik spaeter improvisiert an einen Desktop-Bestand angehaengt wird. Wir planen diese Teile bewusst zusammen.