Razvoj API gatewaya i upravljanje API-jima

API gateway skuplja rutiranje, autentifikaciju, rate limite i logove zahtjeva na jedan sloj, tako da svaki servis prestane da izmišlja svoja ulazna vrata. Mobilne aplikacije, javni API za partnere i vaši admin alati zovu jedan hostname. Iza njega narudžbe, katalog i naplata ostaju odvojeni procesi sa odvojenim deployevima.

U CodeWizu taj sloj dizajniramo i vodimo za Laravel i Node.js sisteme, za monolit koji se sprema na dijeljenje, i za skup servisa do kojih se već dolazi kroz zamršene Nginx lokacije. Gateway je konfiguracija i mala količina politike. Poslovna pravila ostaju u servisima, gdje se mogu testirati bez mrežnog skoka.

Posao je za timove koji API izlažu više od jednog klijenta, za firme koje dodaju partnere kojima trebaju ključevi i kvote, i za svakoga ko želi jedno mjesto na kojem vidi kašnjenje, greške i zloupotrebu. Jedna aplikacija na jednom domenu često treba samo reverse proxy koji već ima. Kada se pojave drugi i treći servis, gateway opravdava svoje mjesto. Tipičan povod je mobilna aplikacija i partnerski pristup koji više ne smiju svaki imati svoj poseban ulaz, sa svojim timeoutom i svojim logom.

API gateway počinje rutiranjem zahtjeva

Rutiranje je mapa od dolaznog zahtjeva do procesa koji treba da odgovori. Jasna mapa je odluka o proizvodu koliko i o mreži: koji URL je javan, koji header bira tenanta, koji dio saobraćaja smije vidjeti novu verziju.

Šta ruta smije da odluči

• Poređenje po hostu, putanji, metodi i, kada zaista treba, po headeru. Ruta koja zavisi od maglovitog regularnog izraza postane nečitljiva čim je uredi druga osoba.
• Slanje zahtjeva na imenovani upstream, sa timeoutom za povezivanje, timeoutom za odgovor i health checkom. Mrtav upstream izlazi iz rotacije umjesto da drži pozivaoce da vise.
• Skidanje vanjskog prefiksa, postavljanje X-Request-Id ako ga pozivalac nije poslao, i prosljeđivanje samo headera kojima servis smije vjerovati.
• Prebacivanje dijela saobraćaja na novu verziju kao canary. Taj dio je broj koji mijenjate bez deploya servisa.

Ponovni pokušaji i timeouti

Ponovni pokušaj je siguran za GET koji nije stigao do servisa. Opasan je za POST koji kreira narudžbu: prvi pokušaj je možda uspio, a pao je samo odgovor. Ponavljamo samo idempotentne pozive, a timeout držimo kraćim od timeouta pozivaoca, tako da spor upstream padne vidljivo umjesto da se zahtjevi slažu. Kratka definicija rute izgleda ovako:

Konkretan fajl je Traefik, Kong, APISIX ili Nginx, zavisno od hostinga. Oblik ostaje isti: poklapanje, upstream, auth, limit. Model rutiranja u Traefiku opisan je u referenci Traefik routera, što je dobra slika deklarativnih ruta i kada je engine drugi.

Rate limiting i kvote ispred svakog servisa

Rate limiting na gatewayu štiti kapacitet prije nego zahtjev potroši konekciju prema bazi. To je gruba kapija: toliko zahtjeva po ključu, po tokenu ili po IP adresi, u jednom prozoru. Servis iza i dalje može nametnuti poslovno pravilo, npr. „pet pretraga u minutu na besplatnom planu“, jer to pravilo traži podatke koje gateway nema.

• Identitet pozivaoca je ključ kad god ga imate. Limit po IP adresi je oslonac za anoniman saobraćaj i loš primarni limit za klijente koji dijele kancelarijski NAT.
• Planovi postaju brojevi: besplatan ključ, partnerski ključ i interni ključ nose različite budžete. Gateway čita nivo iz kredencijala i primjenjuje odgovarajuću politiku.
• 429 je ugovor. Odgovor uključuje Retry-After i stabilno tijelo greške, tako da klijentske biblioteke mogu usporiti umjesto da vrte petlju.
• Burst je eksplicitan. Checkout smije legitimno poslati nekoliko poziva odjednom. Limit dozvoljava kratak burst i i dalje kapa trajni tempo.

Obrasci, uključujući gdje limit treba da živi, stoje u našem vodiču za API rate limiting. Na gatewayu implementiramo rubni dio tog dizajna, a domenske kvote ostavljamo u aplikaciji.

Autentifikacija prije nego zahtjev stigne do servisa

Gateway je mjesto koje dokazuje ko zove, tako da dvadeset servisa ne provjerava JWT svaki na svoj način. Autorizacija koja zavisi od narudžbe, uloge unutar tenanta ili sadržaja reda i dalje pripada servisu koji drži podatke. Razdvajanje ta dva posla i jeste poenta: ivica odgovara na pitanje „ko je ovo“, a servis na pitanje „smije li ova narudžba“. Kada se ta pitanja pomiješaju, svaka izmjena uloga traži izmjenu gatewaya.

• API ključevi za partnere koji zovu server-server, sačuvani kao hash, ograničeni na skup ruta i opozivi bez deploya.
• Provjera JWT-a za vaše vlastite web i mobilne aplikacije: potpis, istek, issuer i audience na ivici. Servis dobija provjerene claimove, a ne sirovi token koji mora ponovo parsirati.
• OAuth2 kada treća strana djeluje u ime korisnika. Gateway radi introspekciju ili provjeru access tokena i prosljeđuje subject.
• mTLS između gatewaya i internih servisa, ili između dvije vaše mreže, tako da ukradeni bearer token nije dovoljan da se pozove servis koji nikad nije trebao biti javan.

Servisi prihvataju headere identiteta samo iz mreže gatewaya. Direktan pristup upstream portovima je zatvoren. Klijent koji može zaobići gateway može zaobići limite i audit log, što ostatak dizajna čini ukrasom.

Nadzor, logovi i tragovi za svaki skok

Gateway koji rutira i zaboravi postaje mjesto na kojem se incidenti kriju. Svaki zahtjev koji prođe treba biti pripisiv: ko je zvao, koja ruta se poklopila, koji upstream je odgovorio, koliko je trajalo i koji status se vratio. Bez toga se „sporo je“ ne može razdvojiti na spor upstream, zagušen limit ili plugin koji zove dodatni servis na svaki zahtjev.

• Access logovi sa id-em zahtjeva, imenom rute, consumerom, statusom, kašnjenjem i kašnjenjem upstreama. Isti id se loguje unutar servisa, tako da se jedan neuspjeli checkout može pratiti od ivice do upita.
• Metrike po ruti: tempo zahtjeva, stopa grešaka i percentili kašnjenja. Alarm gleda stopu grešaka i zasićenje limita, a ne jednu bučnu 500.
• Tragovi preko OpenTelemetryja kada više servisa obrađuje poziv. Gateway počinje ili nastavlja trag, a servisi ga preuzimaju.
• Tabla koju neko otvori tokom incidenta, sa vrhunskim rutama po kašnjenju i po 401, 403, 429 i 5xx. Ako se slika sklapa dan, neće biti sklopljena u trenutku kada treba.

Izvan gatewaya i dalje je bitna jednostavna provjera dostupnosti. Self-hosted monitor dostupnosti kaže da hostname odgovara; metrike gatewaya kažu koja ruta je kriva kada je sporo.

Kong, Traefik, NGINX, APISIX ili Cloudflare

Enginei se razlikuju po načinu konfiguracije i po politikama koje već postoje kao plugini. Ne razlikuju se po poslu. Biramo prema tome kako radite deployment i ko će uređivati rutu za šest mjeseci.

Model plugina u Kongu opisan je u dokumentaciji Kong Gatewaya. Open-source distribuciju koristimo kada su plugini razlog da se izabere Kong. Gdje sajt već stoji iza Cloudflarea, rubna konfiguracija iz naših bilješki o Cloudflare konfiguraciji i origin gateway dijele posao: Cloudflare zaustavlja smeće rano, a origin gateway razumije vaše rute i kredencijale.

API gateway, payment gateway i BFF

Imena se sudaraju, a sistemi treba da ostanu odvojeni. API gateway stoji ispred vaših HTTP servisa. Payment gateway uzima podatke kartice i razgovara sa procesorom. Backend-for-frontend je aplikacija koja oblikuje podatke za jednog klijenta, i može stajati iza API gatewaya umjesto da ga zamijeni.

Plaćanje karticama posebna je izrada, opisana u tekstu o integraciji payment gatewaya. API gateway može rutirati /v1/payments prema tom servisu. Sam ne treba da prikuplja brojeve kartica.

Česte greške API gatewaya koje ispravljamo

• Logika narudžbe, cijene ili dozvola po redu seli se u plugin gatewaya, dok gateway ne postane drugi monolit koji niko ne može lokalno testirati.
• Nema timeouta prema upstreamu, pa zaglavljen servis drži workera u svakom sloju i prekid se širi.
• POST zahtjevi se ponavljaju i na kratkom prekidu nastaju duple narudžbe.
• Upstream portovi ostaju otvoreni na javnoj mreži, pa klijenti preskoče gateway kad god im je nezgodan.
• Jedan zajednički API ključ za svakog partnera, pa se otkriveni ključ ne može opozvati samo jednom pozivaocu.
• Logovi bez id-a zahtjeva, pa „checkout je pao u 14:02“ postane pogađanje.
• Limit po IP adresi kao jedina kontrola, što zaključa cijelu kancelariju, a ukradeni ključ i dalje radi sa mnogo adresa.

Šta određuje cijenu API gateway projekta

Procjenu dajemo nakon popisa ruta, pozivalaca i politika. Reverse proxy ispred jedne aplikacije mali je posao na konfiguraciji. Gateway okrenut partnerima, sa ključevima, nivoima i preseljenjem sa direktnog pristupa, veći je posao.

• Koliko ruta i upstreamova postoji, i koliko su im URL-ovi već stabilni.
• Koji kredencijali trebaju: API ključevi, JWT, OAuth2, mTLS, ili kombinacija.
• Da li se kvote razlikuju po planu, i da li ti planovi već postoje u vašoj bazi.
• Migracija: koji klijenti danas zovu servise direktno i moraju se preseliti bez prekida.
• Okruženja. Gateway koji postoji samo u produkciji iznenadiće vas na prvom staging testu.
• Ko ga poslije vodi: predaja sa tablama, ili stalne izmjene kako se pojavljuju novi servisi.

API gateway se procjenjuje prema toj listi, a procjena se dogovori prije nego što se prva ruta presječe. Ako je trenutna Nginx konfiguracija već prave veličine, to kažemo i tu stanemo.

Kako radimo

1. Analiza: popisujemo hostove, putanje, pozivaoce, kredencijale i timeoute koje svaki servis zaista može ispuniti.
2. Plan: biramo engine, crtamo rute i dogovaramo šta je politika (gateway), a šta domenska logika (servis).
3. Izrada: pišemo konfiguraciju, auth, limite i table, i zatvaramo direktan pristup upstreamovima prvo na staging okruženju.
4. Testiranje: provjeravamo svaku rutu, opozvan ključ, burst preko limita, mrtav upstream i id zahtjeva koji se pojavi u oba loga.
5. Puštanje u rad: pozivaoce selimo grupu po grupu, a stara putanja ostaje dok saobraćaj te grupe ne bude čist.
6. Podrška: držimo rute, plugine i certifikate ažurnim, i doterujemo limite kada stvarno puštanje promijeni oblik saobraćaja.

Zašto CodeWiz

• Full-stack: gradimo Laravel, Node.js i WordPress servise iza gatewaya, pa rute odgovaraju načinu na koji se kod zaista ponaša.
• Open-source na prvom mjestu: Traefik, Kong, APISIX, NGINX i OpenTelemetry, uz Cloudflare tamo gdje ivica koju već plaćate treba da uradi prvo filtriranje.
• Prava veličina: jasna Nginx konfiguracija kada imate jednu aplikaciju; gateway sa consumerima i kvotama kada se pojave partneri.
• Fer cijene: vrhunski razvoj bez vrhunskih cijena, iz Banje Luke, na daljinu sa klijentima iz regiona i svijeta od 2023.
• Performanse i sigurnost zajedno: timeouti, limiti, TLS i logovi jedna su isporuka, a ne naknadni projekat. Više o studiju je na stranici o CodeWizu.

Često postavljana pitanja

Koliko košta izrada API gatewaya?

Jedan proxy ispred jednog ili dva servisa, sa TLS-om, timeoutima i osnovnim logovima, kratak je angažman. Ključevi, kvote po planu, više upstreamova i selidba postojećih klijenata koštaju više, najviše zbog popisa i prelaska. Pisanu procjenu dobijate nakon tog popisa, prije nego što diramo produkcijski saobraćaj.

Da li nam treba API gateway?

Trebate ponašanja: jedan javni hostname, autentifikaciju, limit i log. Jedna aplikacija to može dobiti od Nginxa ili Caddyja bez posebnog proizvoda. Gateway se isplati kada bi nekoliko servisa, ili nekoliko vanjskih consumera, inače svaki napravio svoju kopiju tih ulaznih vrata.

Da li izabrati Kong, NGINX ili Cloudflare?

NGINX odgovara serveru koji već vodite i šaci ruta. Kong ili APISIX odgovaraju mnogim API ključevima i pluginima. Cloudflare odgovara globalnoj ivici i saobraćaju koji želite očistiti prije origina, a autentifikaciju na nivou rute i dalje ostavlja nečemu što poznaje vaše consumere. Biramo prema modelu deploya i ljudima koji će kasnije uređivati rute.

Da li je API gateway isto što i payment gateway?

Nije. Payment gateway pomjera novac i razgovara sa procesorima kartica. API gateway rutira i štiti vaše HTTP API-je. Isti projekat često treba oba: API gateway šalje /v1/payments servisu, a taj servis razgovara sa Stripeom, PayPalom ili bankom.

Da li će gateway usporiti API?

Lokalni gateway dodaje malo, stabilno kašnjenje, obično znatno ispod vremena koje potroši upit prema bazi. Usporavanje koje ljudi primijete dolazi od predugog timeouta, oluje ponovnih pokušaja ili plugina koji na svaki zahtjev zove drugi mrežni servis. Rad gatewaya držimo na provjerama koje može obaviti iz zahtjeva i iz lokalne konfiguracije.

Možete li staviti gateway ispred postojećeg Laravel ili Node.js API-ja?

Možemo. Aplikacija zadržava svoje rute i domenske provjere. Gateway završava TLS, provjerava kredencijal, primjenjuje limit i prosljeđuje zahtjev. Pozivaoce selimo na hostname gatewaya, a zatim zatvaramo stari javni port.

Spremni za jedinstvena ulazna vrata?

Recite nam koji su servisi danas javni i koji pozivaoci treba da imaju ključeve, kvote ili put kroz privatnu mrežu. Predložićemo engine, mapu ruta i prelazak koji ne prekida klijente koje već imate. Kontaktirajte nas da prođemo kroz to, ili pogledajte naše usluge API gatewaya.