API-d ühendavad rakendusi selgete protokollide ja arhitektuuride kaudu. API arhitektuur on tarkvaraliideste loomise reeglite raamistik. Reeglid määravad, kuidas kasutajatele serveri funktsioone pakkuda. Arhitektuuri tüüp määrab API-d reguleerivad reeglid ja struktuurid.
API-arhitektuure on palju erinevat tüüpi, alates REST-ist kuni RPC-ni. Nende struktuuri ja koostise tundmaõppimine aitab teil rakenduse jaoks sobiva valida.
1. PUHASTA
REST API-d on kaasaegsed ja on kõige populaarsem API arhitektuur, mida arendajad kasutavad. PUHASTA (esitusseisundi ülekanne) on arhitektuur, mida kasutatakse klient-server rakenduste kujundamiseks. See ei ole protokoll ega standard, nii et saate seda rakendada mitmel viisil. See aspekt suurendab teie paindlikkust arendajana.
REST võimaldab juurdepääsu taotletud andmetele, mis on salvestatud andmebaasi. CRUD-i põhifunktsioone saate täita REST API-ga. Kui kliendid taotlevad sisu RESTful API kaudu, peavad nad kasutama õigeid päiseid ja parameetreid. Päised sisaldavad kasulikke metaandmeid ressursi tuvastamiseks, näiteks olekukoode ja volitusi.
HTTP kaudu edastatav teave võib olla JSON-, HTML-, XML- või lihttekstina. JSON on REST API-de jaoks kõige sagedamini kasutatav failivorming. JSON on keeleagnostiline ja inimestele loetav.
2. SEEP
Lihtne objektile juurdepääsu protokoll (SOAP) on ametlik API-protokoll. World Wide Web Consortium (W3C) haldab SOAP-protokolli, mis on üks varasemaid API-arhitektuure. Selle disain hõlbustab suhtlust erinevate keelte ja platvormidega loodud rakenduste vahel.
SOAP-vorming kirjeldab API-d, kasutades veebiteenuse kirjelduskeelt (WSDL). See on kirjutatud ulatuslikus märgistuskeeles (XML). Vorming kehtestab sisseehitatud vastavusstandardid, mis suurendavad turvalisust, järjepidevust, isolatsiooni ja vastupidavust. Need omadused tagavad usaldusväärsed andmebaasitehingud, muutes SOAP-i ettevõtte arendamiseks paremaks.
Kui kasutaja taotleb sisu SOAP API kaudu, läbib see standardseid kihiprotokolle. Vastus on XML-vormingus, mida inimesed ja masinad saavad lugeda. Nagu REST API-d, ei salvesta SOAP API-d teavet vahemällu/salvesta. Kui vajate andmeid hiljem, peate esitama uue päringu.
SOAP toetab nii olekuga kui ka olekuta andmevahetust.
3. GraphQL
GraphQL on päringukeel API jaoks. See on serveripoolne käitusaeg, mis täidab päringuid määratletud andmekogumi alusel. GraphQL-il on spetsiifilised kasutusjuhud. Selle arhitektuur võimaldab teil deklareerida konkreetset teavet, mida vajate.
Erinevalt REST-arhitektuurist, kus HTTP käsitleb kliendi päringuid ja vastuseid, küsib GraphQL andmeid päringutega. GraphQL-i teenus määratleb nende tüüpide tüübid ja väljad ning pakub seejärel iga välja ja tüübi jaoks funktsioone.
Teenus võtab vastu GraphQL päringud kinnitada ja teostada. Esiteks kontrollib see päringut veendumaks, et see viitab määratletud tüüpidele ja määratletud väljadele. Seejärel käivitab see soovitud tulemuse saamiseks seotud funktsioonid.
GraphQL on suurepärane teatud kasutusjuhtudel, näiteks andmete toomiseks mitmest allikast. Samuti saate juhtida andmete toomist ja reguleerida väiksemate seadmete ribalaiust.
4. Apache Kafka
Apache Kafka on hajutatud platvorm, mis toetab sündmuste voogesitust. Sündmuste voogesitus on allikatest reaalajas andmete kogumise protsess. Allikad võivad olla andmebaasid, serverid või tarkvararakendused. Kafka süsteem koosneb serveritest ja klientidest. Suhtlus toimub TCP võrguprotokolli kaudu.
Saate süsteemi juurutada riistvarale, virtuaalmasinatele ja konteineritele. Saate seda teha kohapeal ja pilvekeskkondades. Apache Kafka süsteem kogub andmeid, töötleb ja reageerib neile reaalajas. Samuti saab see suunata andmed reaalajas eelistatud sihtkohta. Kafka kogub ja salvestab süsteemi andmeid, mida saate hiljem kasutamiseks hankida.
Kafka toetab pidevat andmete voogu ja integreerimist. See tagab, et teave on õiges kohas ja õigel ajal. Sündmuste voogesitus võib kehtida paljudel kasutusjuhtudel, mis vajavad reaalajas andmevooge. Nende hulka kuuluvad finantsasutused, tervishoid, valitsus, transporditööstus ja arvutitarkvara ettevõtted.
5. AsyncAPI
AsyncAPI on avatud lähtekoodiga algatus, mis aitab luua ja säilitada sündmustepõhiseid arhitektuure. Selle spetsifikatsioonidel on OpenAPI spetsifikatsioonidega palju ühist. AsyncAPI on sisuliselt OpenAPI spetsifikatsioonide kohandamine ja täiustamine, millel on mõned erinevused.
AsyncAPI arhitektuur ühendab REST API-de ja sündmuste juhitud API-de segu. Selle päringute ja vastuste käsitlemise skeemid on sarnane sündmuste API-de omaga. AsyncAPI pakub spetsifikatsioone asünkroonsete rakenduste kirjeldamiseks ja dokumenteerimiseks masinloetaval kujul vormingus. See pakub ka selliseid tööriistu nagu koodigeneraatorid, mis hõlbustavad kasutajatel nende rakendamist.
AsyncAPI parandab sündmustepõhise arhitektuuri (EDA) praegust olekut. Eesmärk on muuta EDA-dega töötamine lihtsamaks, nagu see on REST API-dega. AsyncAPI algatus pakub dokumentatsiooni ja koodi, mis toetavad sündmuste haldamist. Enamik REST API-des kasutatavaid protsesse kehtivad sündmuste juhitud/asünkroonsete API-de puhul.
AsyncAPI spetsifikatsiooni kasutamine sündmustepõhiste süsteemide dokumenteerimiseks on ülioluline. See juhib ja säilitab sündmustepõhiste projektidega töötavate meeskondade järjepidevust ja tõhusust.
6. Remote Procedure Call (RPC)
RPC on tarkvaraline sideprotokoll, mis võimaldab suhelda võrgus erinevate programmide vahel. Näiteks võib programm küsida teavet teiselt võrgus olevalt arvutilt. See ei pea järgima võrguprotokolle. Saate kasutada RPC-d protsesside kutsumiseks kaugsüsteemides nagu kohalikus süsteemis.
RPC töötab klient-serveri mudelil. Klientprogramm küsib ja serveriprogramm vastab teenusega. RPC-d töötavad sünkroonis. Kui programm saadab päringu, jääb see peatatuks, kuni see saab serverilt vastuse.
RPC-d on hajutatud süsteemide jaoks parimad. Need sobivad kõige paremini käsupõhiste süsteemide jaoks ja neil on kerge kandevõime, mis suurendab jõudlust.
Kuidas valida õige API arhitektuur
Õige API arhitektuur sõltub teie kasutusjuhtumist. Arhitektuur määrab API arendamise metoodika ja selle, kuidas see töötab. API arhitektuurne disain määratleb selle komponendid ja koostoimed.
Enne API kavandamist ja arendamist tehke arhitektuurilisi otsuseid. Määrake API tehnilised nõuded, tase, elutsükli haldus ja turvalisus. API arhitektuuri kujundused sisaldavad struktuurikihte. Kihid juhivad arendamist ja tagavad, et loodud API teenib ettenähtud eesmärki.
