
API projektavimo principai keičiamo dydžio sistemoms
API yra sutartis tarp sistemų. Kai ta sutartis gerai suprojektuota, paslaugos gali vystytis nepriklausomai, komandos dirbti lygiagrečiai, o sistema elegantiškai plečiasi esant apkrovai. Kai suprojektuota blogai, kiekvienas pakeitimas tampa koordinacijos košmaru, klientai sugenda diegimų metu, o našumas neprediktuojamai blogėja. Skirtumas dažnai priklauso nuo kelių projektavimo sprendimų, priimtų anksti projekte.
REST ir gRPC: tinkamo protokolo pasirinkimas
REST per HTTP/JSON išlieka plačiausiai priimtu API stiliumi dėl geros priežasties: jis žmogui skaitomas, universaliai palaikomas įrankių ir paprastas derinti. Viešosioms API ir žiniatinklio programoms REST vis dar yra pragmatiškas numatytasis pasirinkimas. Tačiau vidinei tarnybų tarpusavio komunikacijai, kur svarbu vėlavimas ir pralaidumas, gRPC siūlo įtikinamų pranašumų. Jo dvejetainė Protocol Buffer serializacija yra 5-10 kartų kompaktiškesnė nei JSON, HTTP/2 multipleksavimas pašalina eilės pradžios blokavimą, o griežtai tipizuoti paslaugų apibrėžimai iš .proto failų aptinka sutarties pažeidimus kompiliavimo metu.
Versijų kūrimas nesulaužant klientų
API versijų kūrimas yra mažiau apie mechanizmą — URL kelią (/v1/), antraštę ar užklausos parametrą — ir daugiau apie sutartį su vartotojais. URL pagrįstas versijų kūrimas yra aiškiausias ir lengviausiai nukreipiamas apkrovos balansuotojo lygmeniu. Tikroji disciplina yra tai, kas sudaro laužantį pakeitimą. Naujų laukų pridėjimas prie atsakymo nelaužo. Laukų pašalinimas ar pervadinimas — laužo. Lauko tipo keitimas — laužo. Tvirta versijų strategija palaiko bent dvi aktyvias versijas vienu metu su paskelbtu pasenimo grafiku ir migracijos vadovais.
Greičio ribojimas, idempotentiškumas ir klaidų apdorojimas
Greičio ribojimas apsaugo jūsų sistemą nuo piktnaudžiavimo ir užtikrina teisingą išteklių paskirstymą tarp vartotojų. Įdiekite jį API vartų lygmeniu naudodami token bucket arba slankiojo lango algoritmus ir visada grąžinkite standartines antraštes — X-RateLimit-Limit, X-RateLimit-Remaining, X-RateLimit-Reset. Mutacijos galiniams taškams idempotentiškumas yra nederamas. Kai klientas pakartoja nepavykusią POST užklausą, turite garantuoti, kad operacija vykdoma daugiausia vieną kartą. Standartinis šablonas — Idempotency-Key antraštė. Klaidų atsakymai turi sekti nuoseklią schemą visuose galiniuose taškuose.
Pagrindiniai principai, kuriuos reikia įterpti į kiekvieną API projektą:
- Projektuokite atgaliniam suderinamumui nuo pirmos dienos. Papildomi pakeitimai yra saugūs; pašalinimai ir pervadinimai reikalauja naujos versijos.
- Naudokite žymeklio puslapiavimą dideliems duomenų rinkiniams. Postūmio puslapiavimas sugenda lygiagrečių rašymų metu ir lėtėja giliuose puslapiuose.
- Padarykite kiekvieną klaidos atsakymą veiksmingą. Įtraukite, kas nutiko, kodėl ir ką klientas gali padaryti.
Gerai suprojektuotos API kaupia vertę laikui bėgant. Kiekvienas vartotojas, kuris sklandžiai integruojasi, kiekvienas diegimas, nesulaužantis klientų, ir kiekvienas incidentas, išvengtas tinkamu greičio ribojimu ir idempotentiškumu, sudaro inžinerinį greitį, kurio blogai suprojektuotos API tiesiog negali pasiekti. OKINT Digital dirba su komandomis, projektuodami API kaip stabilius, keičiamo dydžio pamatus paskirstytosioms sistemoms.
Norite aptarti šias temas nuodugniau?
Mūsų komanda pasiruošusi architektūros peržiūroms ir strateginėms sesijoms.
Suplanuoti konsultaciją →