Egy technikai tárgyaláson gyakran elhangzik a mondat: „ez API-n keresztül megy majd". A legtöbb kkv-vezető ilyenkor bólint, és reméli, hogy ez azt jelenti, minden rendben lesz — anélkül, hogy pontosan értené, mire vállalkozik a csapata vagy a partnere. Ehhez a cikkhez nem kell fejlesztőnek lenned; a cél az, hogy értsd, mit jelent valójában egy API-integráció, és melyik kérdéseket kell feltenned, mielőtt igent mondasz egy projektre.

Az API egyszerűen: egy megállapodás két rendszer között

Képzeld el az API-t úgy, mint egy éttermi étlapot két rendszer között. A te rendszered nem nyúlhat bele a másik rendszer belső működésébe — nem látja, hogyan tárolja az adatot, hogyan dolgozza fel a kéréseket —, csak azt teheti meg, amit az étlap felkínál: „kérd le a rendelés státuszát", „hozz létre egy új ügyfelet", „frissítsd a készletet". Az API pontosan ez az étlap: egy pontosan meghatározott lista arról, mit lehet kérni, és mit fogsz kapni válaszul.

Ez a megközelítés azért fontos neked, mint döntéshozónak, mert megmutatja, hol vannak a korlátok. Ha egy integráció olyat próbál csinálni, amire az étlapon nincs tétel — mert a másik rendszer egyszerűen nem kínálja fel azt a lehetőséget —, akkor az integráció nem lehetséges, függetlenül attól, mennyire ügyes a fejlesztőd. Ez az első, legfontosabb kérdés minden integrációs projekt elején: a másik rendszer valóban felkínálja-e API-n azt a funkciót, amire szükségünk van? Ezt mindig a projekt elején kell tisztázni, nem a végén felfedezni.

Mi az, ami valóban megbízhatóvá tesz egy integrációt

Két rendszer összekötése ritkán az a „bekapcsoljuk és kész" feladat, amilyennek első hallásra tűnik. Az egyik legfontosabb, gyakran alábecsült kérdés az, mi történik, amikor valami nem sikerül — a másik rendszer éppen nem válaszol, lassú, vagy hibát ad vissza. Egy jól megtervezett integráció ilyenkor nem veszíti el az adatot, hanem újrapróbálkozik, vagy legalább jelzi, hogy valami nem sikerült, hogy tudjátok utólag kezelni. Egy rosszul megtervezett integráció ezzel szemben csendben elveszíti a rendelést vagy az adatot, és hetekig senki nem veszi észre, amíg valaki nem hiányol valamit.

A másik fontos kérdés a hitelesítés és jogosultság: honnan tudja a másik rendszer, hogy valóban te kérdezel tőle, és mihez van jogosultságod. A jó gyakorlat szerint az integráció csak azt az adatot és funkciót érheti el, amire tényleg szükség van — nem a teljes rendszert. Ha egy webshop-integráció a teljes ügyfél-adatbázishoz hozzáférést kap, amikor valójában csak a rendeléskezeléshez lenne szükséges, ez felesleges kockázatot jelent, ami előbb-utóbb megbosszulja magát.

A kérdések, amiket a tárgyaláson feltehetsz

Nem kell technikai részletekbe belemenned ahhoz, hogy jó döntéseket hozz — elég néhány konkrét kérdést feltenni, és figyelni a válaszok minőségét. Kérdezd meg, mi történik, ha az egyik rendszer nem elérhető — ha a válasz bizonytalan vagy elmossa a kérdést, ez jelzi, hogy a hibakezelést még nem gondolták végig. Kérdezd meg, mennyi ideig tart, amíg egy változás átfut a másik rendszerbe — azonnali, néhány perces, vagy órás késleltetéssel — mert ez az, amit a napi működésedben tapasztalni fogsz.

Ha egy fejlesztő nem tud egyszerű nyelven válaszolni arra, mi történik hiba esetén, az integráció valószínűleg működni fog — addig, amíg először nem történik hiba.

Kérdezd meg végül, hogyan fogjátok tudni, ha valami elromlott — van-e riasztás, vagy csak akkor derül ki, amikor egy ügyfél panaszkodik. Ez az utolsó kérdés az, amelyik a legtöbbet elárulja arról, mennyire komolyan gondolták végig a hosszú távú üzemeltetést, nem csak az első, sikeres teszt-lefutást.

Ha egy integrációs projekt előtt állsz, és szeretnéd, hogy valaki a te oldaladon is átgondolja a kockázatokat, szólj nekünk — szívesen segítünk a helyes kérdéseket feltenni.