API-First

Az API-First vagy Contract First egy szoftverfejlesztési koncepció, melynek célja különböző, egymással kommunikáló szoftverek fejlesztésének elősegítése. A megközelítés lényege, hogy először a szoftverek kommunikációját, protokollját határozzuk meg (ez az ún. „contract”), majd pedig ehhez fejlesztjük le az egyes részszoftvereket. A „contract” (szerződés) itt részben a szoftverrészek közti kommunikáció specifikációja, részben pedig az őket fejlesztő munkacsoportok közti megállapodást is jelent.

Történet, okok

Egymással kommunikáló szoftverek már az „informatikai ősidőkben”, kb. a 60-as évektől fogva léteznek. Az Internet fejlődése körülbelül a 2000-es évek vége óta a következő változásokhoz vezetett:

1. Az egyes, egymással kommunikáló szoftverelemek igen különböző nyelveket, szabványokat használnak (például Java a szerveroldalon és JavaScript a felhasználói PC-ken).
2. Az egyes szoftverelemek fölötti kontroll gyakran korlátolt (például még a Google sem tudja garantálni, hogy a felhasználók frissítik-e a Gmail appjukat).
3. A szoftverek különböző komponenseit külön munkacsoportok írják, kommunikációjuk nem mindig lehetséges, általában szervezeti vagy időbeli korlátok miatt.
4. Az egyes részszoftverek munkaóraigénye gyakran igen nagy, komplex vállalati struktúrák szervezik őket.
5. Ugyanakkor viszont az évtizedek alatt nagy tapasztalat gyűlt össze a szoftverfejlesztés és projektmenedzsment vonalon.

Az „API-First” kialakulásához az a megfigyelés vezetett, hogy az elkészülő, több szoftver együttműködésére alapuló szoftvertermék minősége jobb, és a fejlesztési költségek alacsonyabbak, amennyiben a kommunikációjukat, vagy legalábbis annak belátható részét, még a tervezési fázis legelején meghatározzuk.

Bevezetés

Két alapvető projektmenedzsment szempontot kell számon tartani:

1. Mivel egymással kommunikáló, de minden szempontból lényegesen különböző szoftverekről van szó, valamiféle, a kommunikációjukra vonatkozó közös tudásnak léteznie kell már a fejlesztés megkezdése előtt.
2. Mivel pedig ez a közös tudás természetéből adódóan nem lehet teljes (számos probléma, változtatási igény csak a tervezés/fejlesztés későbbi fázisaiban merül fel), a lehető leghamarabb és a lehető legteljesebb contract létrehozására van szükség.

Előnyök, következmények:

1. Ami a contractba nem kerül bele, az implementációs fázisból is kimarad. Ebből kifolyólag hamarabb érhető el a teljes szoftverrendszer egy legalább részlegesen működő változata.
2. Mivel az implementáció részletei a contract létrehozásakor még nem ismertek, az alapvetően a tények alapján épül fel, „tiszta lesz” - implementációs részletkérdések még nem befolyásolják.
3. A contract egy formalizált, valamint programnyelvtől- és keretrendszertől független dokumentum, ezért annak minden egyes használója alkalmazhatja a saját, rendelkezésre álló fejlesztéstámogató eszközeit (kódgenerálás, automatizált tesztelés, mock adat generálás stb.) a fejlesztés gyorsítására.

Open API / Swagger

A mai gyakorlatban túlnyomórészt REST, ritkábban SOAP protokollt használnak. Az OpenAPI (korábbi nevén Swagger) egy nyílt szabvány a REST alapú kommunikáció formalizálására.

Források

• API-First bevezető (angol)