API vs API

negativEgy új webes szolgáltatás bevezetésénél és népszerűsödésében egyre nagyobb és nagyobb súllyal esik latba, hogy a szolgáltatás rendelkezik-e valamiféle API-val és ha igen akkor az hogyan is funkcionál. Nem lehet véletlen, hogy a Google is egyre inkább rászokik arra, hogy minden újdonságát API-val együtt vezet be. Arra keressük ma a választ, hogy a webes szolgáltatásoknak kell-e API-t nyitniuk, vagy sem, mikor, miért és mennyire.

API helyzet

Praktikusan minden Google termék rendelkezik valamiféle publikus API-val. Ezzel szemben mondjuk a LinkedIn nem. Jobban mondva van LinkedIn API de nem publikus, és alig alig adnak hozzáférést. Ha valaki kicsit utána turkál akkor biztosan talál még olyan webes szolgáltatást ami népszerű de nincs hozzá hivatalos API. A hivatalos szó itt azért fontos, mert kis erőbefektetéssel egy közepes hozzáértéssel rendelkező webes programozó képes bármihez API-t kreálni. Ott van például a tény, hogy az iwiw nem enged hozzáférést a hírfolyamhoz és egyelőre nincs Iwiw REST API. Legalábbis hivatalosan. Nem hivatalosan igenis van Iwiw hírfolyam API.

Sok esetben az is előfordul, hogy a nem hivatalos API-k végül hivatalossá vállnak.

Érvek mellette és ellene

Az API nyitás melletti és elleni érvek majdnem azonosak. A kérdés az, hogy ezek a tények mennyire befolyásolják a szolgáltatás üzleti modelljét, azaz az API bevezetésével a szolgáltatás nyerni vagy veszíteni fog.

Egy API-t költséges összerakni
Hát, igen, minden munka költséggel jár. Egy API létrehozása bevezetésének időpontjától és a kínált szolgáltatások számától függ. A tervezés és kivitelezés során minél korábban körvonalazódik az API annál kevésbé lesz költséges. A nem hivatalos API-k a legjobb bizonyítékok arra, hogy nem a költség a fő gond.
Az API önmagában egy biztonsági rés
Nem jobban mint egy html form ámbátor tény, hogy a biztonságra is oda kell figyelni.
Az API nyitással látogatókat és felhasználókat fogunk veszteni, mivel a máshová beépült szolgáltatásrészeinket fogják használni a weblapunk helyett.
Ez tény, erre (is) szolgál az API. Ez az a pont amit meg kell vizsgálni üzleti szempontból.

Üzleti modellek

Többféle üzleti modell is megtámogathatja az API-t. Lássuk ezek közül a főbbeket.

A beépülő modell

Egyes szolgáltatások (mint a Facebook vagy éppen az Iwiw) azért nyitnak API-t, hogy fejlesztők új szolgáltatásokkal bővítsék az alap szolgáltatást. Ezekben az esetekben az API-t használó alkalmazás sok esetben önállóan, azaz a fő szolgáltatástól függetlenül működésképtelen és vagy értelmetlen. Ilyenkor az API nyitás nem látogatószám csökkenést, hanem a bővülő szolgáltatások és felhasználói élmény miatt látogatószám növekedést hoz.

Fizetős API modell

Ebben a modellben az API használata részben vagy egészben fizetős, azaz a fejlesztőknek fizetniük kell amennyiben használni akarják. Ilyen lehet mondjuk, hogy egy real-time felé kacsingató API az ingyenes usereknek beiktat egy 30 másodperces delayt, míg a fizetősek a szünet nélkül kapják meg az adatokat. Fizetős API-kat is nagyon jól össze lehet tenni, de csak akkor működnek ha a szolgáltatáson keresztül maguk a userek is hajlandóak időnként a zsebükbe nyúlni.

Az API korlátos modell

Ennél a modellnél az API bizonyos funkciókat egyáltalán nem integrál, azokat csak az eredeti szolgáltatásban lehet elvégezni. Ezzel minden felhasználót rákényszerítünk arra, hogy legalább néha ellátogasson az eredeti szolgáltatás weboldalára.

API jövőkép

Általánosságban az eddigi trendek alapján általános API előretörés várható. A mobil platform erősödésével, a mashup-ok elterjedésével egyre másra fel fognak olyan szolgáltatások bukkanni amelyek valamilyen szempontból többet fognak kínálni mint az eredeti szolgáltatás. Ha belegondolunk abba, hogy a 10 ezer magyar twitterezőre már legalább 6 magyar twitter fejlesztés jut (Turulcsirip, Yamm, Twitteverest, Twittertop, Sociall, Csiripmap) akkor láthatjuk, hogy mennyire erős ez a trend már ma is. (Zárójelben: segíts nekem összeszedni a magyar fejlesztésű twitter szolgáltatásokat.)

Röviden ha valaki webes szolgáltatás fejlesztésben gondolkozik akkor minél előbb építse be a modelljébe valamilyen módon az API-t.

Vélemény, hozzászólás?

Az email címet nem tesszük közzé. A kötelező mezőket * karakterrel jelöljük.