Aki a végpontok számából becsüli meg az egyedi API-fejlesztés költségét, tévedni fog, jellemzően háromszoros mértékben. A végpontok jelentik a legolcsóbb részt. Egy tucat végpont, amely a már meglévő adatait olvassa és írja, két hét munka egy hozzáértő backend-fejlesztőnek.

Az kerül pénzbe, ami ezekből a végpontokból olyasmit csinál, amire egy másik cég ráépíti az üzletét: hitelesítés, amely átmegy egy biztonsági auditon, verziózás, amely megengedi, hogy később meggondolja magát, dokumentáció, amely elég jó ahhoz, hogy senki ne írjon e-mailt, és az az üzemeltetési apparátus, amely megmondja, melyik ügyfélnek van rossz reggele. A büdzsé abban a résben lakik, amely a „van egy API-nk" és a „van egy API-nk, amelyre mások támaszkodnak" között húzódik.

Ársávok egy pillantásra: egy belső API, amelyet csak a saját alkalmazásai használnak, jellemzően 10 000 és 30 000 font közé esik. Egy partner-API, amelyet néhány megnevezett integrátor használ, általában 40 000 és 100 000 font között mozog. Egy nyilvános API, amely a termék része, önkiszolgáló regisztrációval és közzétett szerződéssel, 100 000 font körül kezdődik, és az indulás után is költséget termel.

Amit valójában megvásárol

Az API termék, amelynek felhasználói vannak, és szüksége van mindarra, amire a termékeknek. Ezt a listát egy árajánlathoz mérni a leggyorsabb módja annak, hogy meglássa, mi hiányzik belőle.

Tervezés és szerződés. Valakinek el kell döntenie az erőforrásmodellt, az elnevezési konvenciókat, a hibaformátumot, a lapozás módját és a szűrés szintaxisát, majd le kell írnia specifikációként, még mielőtt a megvalósítás elkezdődik. Ennek kihagyása olyan API-t eredményez, amelyben három végpont háromféleképpen oldja meg ugyanazt a problémát, és ezt a fogyasztók azonnal észreveszik.

Hitelesítés és jogosultságkezelés. Az API-kulcs egyszerű, és belső használatra megfelelő. A partneri és a nyilvános API-knak rendszerint valódi, tokenalapú folyamatra van szükségük hatókörökkel, lejárattal és rotációval, valamint fogyasztónkénti jogosultságokra, amelyeket minden kérésnél ellenőrizni kell, nem pedig a kulcsból következtetni rájuk.

Sebességkorlátozás és kvóták. A fogyasztónkénti korlátok megvédik az infrastruktúrát egyetlen integrátor elszabadult kötegelt feladatától. Ezeket a válaszfejlécekben is közölni kell, hogy a jól nevelt kliensek visszavehessenek a tempóból, és kell hozzájuk kivételes út annak az ügyfélnek, akinek jogosan van szüksége többre.

Amiről a fogyasztók ítéletet mondanak

Dokumentáció. A generált referencia csak a belépőszint. Amire a fogyasztóknak valóban szükségük van, az egy kezdőútmutató, egy hitelesítési bemutató, kidolgozott példák néhány nyelven és egy változásnapló. A jó dokumentáció valódi, hetekben mérhető szállítandó, és ez dönti el, hogy egy API magától terjed-e, vagy örökre támogatási jegyeket termel.

Egy homokozó. A partnerek nem fognak az éles rendszeren tesztelni, és ezt Önnek sem érdeke kívánni. A valósághű adatokkal, visszaállítható állapottal és azonos ellenőrzési szabályokkal működő tesztkörnyezet az egyik leggyakrabban kihagyott tétel az API-árajánlatokban, és az egyik leggyakrabban követelt funkció az indulás után.

Megfigyelhetőség. Látnia kell a kérésmennyiséget, a hibaarányt és a késleltetést fogyasztónkénti bontásban, mert a „lassú az API" csak akkor kezelhető, ha meg tudja mondani, kinek a kérései lassúak. A korrelációs azonosítók, amelyekkel egy ügyfél hibázó hívása végigkövethető a naplókban, már a támogatás első hónapjában megtérülnek.

Tesztelés. Az egységteszteken túl az API-nak szerződéses tesztekre van szüksége, amelyek megbuktatják a fordítást, ha egy válasz szerkezete véletlenül megváltozik. Ez a védőháló teszi lehetővé, hogy tovább fejlesszen anélkül, hogy eltörné az Önben megbízó integrátorokat.

A három szint, és miért térnek el ennyire

Ugyanaz a végpontkészlet nagyon eltérő összegbe kerül attól függően, hogy ki használja, mert a közönség határozza meg, mennyi tökéletlenséget visel el.

A belső API-k a saját alkalmazásait szolgálják ki. A csapata mindkét végét kézben tartja, a törő változások egyeztethetők, a dokumentáció lehet szűkszavú, a hitelesítés pedig támaszkodhat a hálózati határokra. Jellemző költség: 10 000 és 30 000 font között egy rendesen megépített szolgáltatásért, ésszerű tesztekkel és felügyelettel.

A partner-API-k külső szervezetek ismert körét szolgálják ki. Most már valódi hitelesítésre, értelmes hibaüzenetekre, homokozóra, megírt dokumentációra és verziózási szabályzatra van szüksége, mert nem gördíthet ki törő változást kedd délután abban a reményben, hogy mindenki lépést tart. Jellemző költség: 40 000 és 100 000 font között az erőforrások számától és a biztonsági követelmények szigorától függően.

A nyilvános vagy termék-API-k mindenkit kiszolgálnak, aki regisztrál. Önkiszolgáló regisztráció, kulcskezelés, közzétett sebességkorlátok, állapotoldal, használatalapú mérés, teljes körű dokumentáció és támogatási folyamat mind szükségessé válik. Ha a számlázás a használattól függ, épített egy mérési és egyeztetési rendszert is. Jellemző költség: 100 000 fonttól felfelé, és az indulás a költés kezdete, nem a vége.

Őszintén eldönteni, melyik szintet építi, a projekt legértékesebb fél órája. Ebben a kategóriában a legtöbb költségtúllépés abból ered, hogy valaki belső API-ként keretezte a munkát, majd három hónappal később kiderült, hogy egy partner mindig is használni fogja.

Hová megy valójában az egyedi API-fejlesztés költsége

Egy partneri minőségű API esetében a ráfordítás elég kiszámíthatóan oszlik meg, és ritkán úgy, ahogy az érintettek várják.

Nagyjából egyötöd megy tervezésre és specifikációra, beleértve az erőforrások elnevezéséről szóló vitákat, amelyek pazarlásnak tűnnek, és hónapnyi következetlenséget előznek meg. További nagyjából egyötöd magára a végpontok megvalósítására, vagyis pontosan arra a részre, amelyet mindenki maga elé képzel, amikor jóváhagyja a keretet.

A hitelesítés, a jogosultságkezelés és a sebességkorlátozás együtt gyakran tizenöt-húsz százalékot visz el, többet is, ha egy meglévő, saját elképzelésekkel rendelkező identitásszolgáltatóhoz kell illeszkednie. A dokumentáció, a homokozó és az esetleges klienskönyvtárak hasonló arányt kérnek, ami meglepi az embereket, amíg meg nem próbálnak jó kezdőútmutatót írni.

A tesztelés, a megfigyelhetőség és az üzembe helyezés viszi el a maradékot. Ezt az utolsó negyedet húzzák ki a leggyakrabban, amikor közeleg a határidő, és éppen ez a húzás fordítja át az egyszeri építési költséget tartós támogatási teherré.

Hogy ez hogyan illeszkedik egy szállítási költségvetés többi tételéhez, arról az egyedi szoftverfejlesztés költségeiről szóló útmutatónk ír részletesen.

Döntések, amelyek elmozdítják a számot

Néhány döntés magyarázza az árajánlatok közötti eltérés nagy részét.

Szinkron vagy aszinkron. Ha bármely művelet egy-két másodpercnél tovább tart, feladatmodellre lesz szüksége: fogadja a kérést, adjon vissza egy hivatkozást, a fogyasztó pedig kérdezzen rá vagy kapjon visszahívást. Ez érezhetően nagyobb építés, mint az egyszerű kérés és válasz, és ha webhookot is kínál, mostantól saját kézbesítési rendszert üzemeltet újrapróbálkozással, aláírás-ellenőrzéssel és külön tárolóval a kézbesíthetetlen üzeneteknek.

Több bérlő kiszolgálása. Annak biztosítása, hogy az egyik ügyfél soha ne lássa a másik adatait, könnyen leírható és könnyen elrontható finom módon. Rendesen megcsinálni, az adathozzáférési rétegben ellenőrzött jogosultsággal az egyes vezérlők helyett, többe kerül, és nem opcionális.

Megfelelőségi kötelezettségek. Ha személyes adatot, fizetési adatot vagy egészségügyi információt kezel, azzal jár az auditnapló, a megőrzési szabály, a titkosítási követelmény és a bizonyítékgyűjtés. Ezek ritkán szerepelnek egy kezdeti becslésben, és később soha nem alkuképesek.

Szolgáltatási szintre vállalt kötelezettség. Egy szerződéses rendelkezésre állási céllal működő API redundanciát, riasztást és ügyeletest igényel. Ez üzemeltetési és nem építési költség, és külön kell árazni, hogy senkit ne érjen meglepetés.

Meglévő alapok. Olyan kódbázisra építeni, amelyben már van hitelesítés, háttérfeldolgozás és felügyelet, drámaian olcsóbb, mint a nulláról indulni. Ha a mögöttes platformra is szüksége van, a szervermentes API építéséről Cloudflare Workersszel szóló írásunk olyan megközelítést mutat, amely alacsonyan tartja az infrastruktúra költségét.

Költségek, amelyek az indulás után érkeznek

Az API ígéret, az ígéreteknek pedig van fenntartási költségük.

A verziózás a legnagyobb tétel. Amint külső fogyasztók függenek a válaszok szerkezetétől, nem változtathat rajtuk szabadon. Két verziót párhuzamosan karbantartani, amíg az integrátorok átállnak, normális, és azt jelenti, hogy minden hibajavítást egy ideig kétszer kell alkalmazni. A közzétett, nagyvonalú felmondási idővel dolgozó kivezetési szabályzat kezelhetővé teszi ezt; hiánya minden fejlesztést tárgyalássá változtat.

A támogatás a második. Még a kiváló dokumentáció is kérdéseket szül, és a kérdések elég technikaiak ahhoz, hogy fejlesztőhöz jussanak, nem pedig megálljanak egy ügyfélszolgálati pultnál. Tervezzen erre valódi fejlesztői időt, különösen az egyes új partnerek élesítését követő hónapokban.

A dokumentáció karbantartása a harmadik és a leginkább elhanyagolt. A már nem működő példák rosszabbak a példák hiányánál, és gyorsabban rombolják a bizalmat, mint egy leállás.

Tervezési számként éves szinten az eredeti építési költség tizenöt-huszonöt százalékával számoljon, hogy egy partneri vagy nyilvános API egészséges maradjon. Ha maga az API bevételi forrás, a szoftverlicencelési modellekről szóló útmutatónk tárgyalja az üzleti oldal felépítését.

Hogyan előzze meg, hogy a projekt megduplázódjon

Három szokás tartja az API-projekteket a becslésükön belül.

Először a specifikációt írja meg, és nézesse át egy valódi fogyasztóval, mielőtt a megvalósítás elindul. Egy óra visszajelzés attól a csapattól, amely ténylegesen integrálni fog, heteknyi újramunkát spórol, és felszínre hozza azt a követelményt, amelyet senki nem említett.

Építsen meg egyetlen végpontot teljesen, végig a hitelesítésen, hibakezelésen, dokumentáción, teszteken és felügyeleten, mielőtt a másik húszhoz hozzáfog. Az első megmutatja a végpontonkénti valódi költséget, méghozzá akkor, amikor a keret még elbírja a hírt.

Legyen könyörtelen a kezdeti erőforráslistával. A legtöbb API több végponttal indul, mint amennyit bárki használ, és minden nem használt végpontot dokumentálni, tesztelni, védeni és verziózni kell, ameddig létezik. Szállítsa a legkisebb hasznos felületet, és bővítse akkor, amikor a valódi használat megmondja, mi hiányzik.

Építsen olyan API-t, amelyet szívesen integrálnak

A Mecanik az egyedi szoftverfejlesztési szolgáltatásaink részeként tervez és épít API-kat, a belső szolgáltatásoktól az önkiszolgáló regisztrációval működő nyilvános termék-API-kig. A specifikációt, a dokumentációt és a homokozót szállítandóként kezeljük, nem utógondolatként, mert éppen ezek döntik el, hogy sikerül-e bárkinek integrálódnia.

Ha a probléma másik oldalán áll, és mások API-ját használja ahelyett, hogy sajátot tenne közzé, a külső API-k integrálásáról szóló útmutatónk elmondja, mire érdemes figyelni. Egyébként mondja el, kik a fogyasztók és mit kell tenniük, mi pedig szintről szintre lehatároljuk, hogy pontosan lássa, mibe kerül az ambíció egyes fokozata.

Kapcsolódó bejegyzések: Szoftverfejlesztés kiszervezése brit céghez , CRM- és ERP-integráció: költségek és buktatók , Mainframe-modernizáció: rewrite, refactor vagy replatform .

Gyakran ismételt kérdések

Mennyibe kerül az egyedi API-fejlesztés? Egy belső API jellemzően 10 000 és 30 000 font közé esik, egy partner-API 40 000 és 100 000 közé, egy nyilvános termék-API pedig 100 000 fölé. Az árat sokkal inkább a közönség hajtja, mint a végpontok száma, mert a külső fogyasztók dokumentációt, homokozót, verziózást és támogatást várnak.

Mennyi ideig tart egy egyedi API megépítése? Egy belső szolgáltatás általában négy-nyolc hét. Egy partneri minőségű API rendszerint három-öt hónap, a dokumentációval és a tesztkörnyezettel együtt. Az önkiszolgáló regisztrációval és használatméréssel működő nyilvános API-k gyakran hat hónapot vagy többet igényelnek az indulásig.

Mitől lesz az API-fejlesztés a vártnál drágább? A dokumentációtól, a homokozó környezetektől, a fogyasztónkénti sebességkorlátozástól, a verziózás támogatásától és a megfigyelhetőségtől. Ezek ritkán jelennek meg a korai becslésekben, együtt viszont gyakran a teljes ráfordítás felét teszik ki egy partneri vagy nyilvános API esetében.

REST vagy GraphQL API-t érdemes építeni? A REST marad a biztonságosabb alapértelmezés a partneri és nyilvános API-khoz, mert az eszközkészlet, a gyorsítótárazás és a fejlesztői ismertség szélesebb. A GraphQL a belső használathoz és a rugalmas lekérdezéseket igénylő gazdag kliensekhez illik, de a költséget a lekérdezések komplexitáskorlátaiba és a jogosultságkezelésbe tolja.

Milyen folyamatos költségekre kell számítani az API indulása után? Évente az építési költség tizenöt-huszonöt százalékával tervezzen. Ez fedezi a párhuzamos verziók karbantartását a kivezetési időszakokban, az integrációs kérdésekre fordított fejlesztői időt, a dokumentáció frissítését és a külső fogyasztók kiszolgálásához szükséges felügyeletet.